Merge branch 'fixes-modulesplit' into fixes
This commit is contained in:
Tony Lindgren
Коммит
d30cc16c8e
|
|
@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices
|
|||
a dump device, as kdump requires resetting the device in order
|
||||
to work reliably.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
|
||||
Date: July 2011
|
||||
Kernel Version: 3.0
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Value of "simple" indicates that the controller has been placed
|
||||
in "simple mode". Value of "performant" indicates that the
|
||||
controller has been placed in "performant mode".
|
||||
|
|
|
|||
|
|
@ -166,8 +166,8 @@ if (condition)
|
|||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if one branch of a conditional statement is a single
|
||||
statement. Use braces in both branches.
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
|
|
|
|||
|
|
@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the
|
|||
implementation may choose to ignore flags that affect the location of
|
||||
the returned memory, like GFP_DMA).
|
||||
|
||||
void *
|
||||
dma_zalloc_coherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, gfp_t flag)
|
||||
|
||||
Wraps dma_alloc_coherent() and also zeroes the returned memory if the
|
||||
allocation attempt succeeded.
|
||||
|
||||
void
|
||||
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle)
|
||||
|
|
|
|||
|
|
@ -2486,6 +2486,9 @@ ioctls.</para>
|
|||
<listitem>
|
||||
<para>Flash API. <xref linkend="flash-controls" /></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the
|
|||
<entry>Enables a power line frequency filter to avoid
|
||||
flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are:
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2).</entry>
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_AUTO</constant> (3).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_HUE_AUTO</constant></entry>
|
||||
|
|
|
|||
|
|
@ -927,6 +927,33 @@ ioctl is called.</entry>
|
|||
Applications set or clear this flag before calling the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>The buffer has been prepared for I/O and can be queued by the
|
||||
application. Drivers set or clear this flag when the
|
||||
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_PREPARE_BUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
|
||||
linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>Caches do not have to be invalidated for this buffer.
|
||||
Typically applications shall use this flag if the data captured in the buffer
|
||||
is not going to be touched by the CPU, instead the buffer will, probably, be
|
||||
passed on to a DMA-capable hardware unit for further processing or output.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
|
||||
<entry>0x0800</entry>
|
||||
<entry>Caches do not have to be cleaned for this buffer.
|
||||
Typically applications shall use this flag for output buffers if the data
|
||||
in this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||
in which case caches have not been used.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -469,6 +469,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-close;
|
||||
&sub-ioctl;
|
||||
<!-- All ioctls go here. -->
|
||||
&sub-create-bufs;
|
||||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-register;
|
||||
|
|
@ -511,6 +512,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-queryctrl;
|
||||
&sub-query-dv-preset;
|
||||
&sub-querystd;
|
||||
&sub-prepare-buf;
|
||||
&sub-reqbufs;
|
||||
&sub-s-hw-freq-seek;
|
||||
&sub-streamon;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,139 @@
|
|||
<refentry id="vidioc-create-bufs">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_CREATE_BUFS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_CREATE_BUFS</refname>
|
||||
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_create_buffers *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_CREATE_BUFS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
|
||||
mapped</link> or <link linkend="userp">user pointer</link>
|
||||
I/O. It can be used as an alternative or in addition to the
|
||||
<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
|
||||
is required. This ioctl can be called multiple times to create buffers of
|
||||
different sizes.</para>
|
||||
|
||||
<para>To allocate device buffers applications initialize relevant fields of
|
||||
the <structname>v4l2_create_buffers</structname> structure. They set the
|
||||
<structfield>type</structfield> field in the
|
||||
<structname>v4l2_format</structname> structure, embedded in this
|
||||
structure, to the respective stream or buffer type.
|
||||
<structfield>count</structfield> must be set to the number of required buffers.
|
||||
<structfield>memory</structfield> specifies the required I/O method. The
|
||||
<structfield>format</structfield> field shall typically be filled in using
|
||||
either the <constant>VIDIOC_TRY_FMT</constant> or
|
||||
<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
|
||||
<structfield>sizeimage</structfield> fields to fit their specific needs. The
|
||||
<structfield>reserved</structfield> array must be zeroed.</para>
|
||||
|
||||
<para>When the ioctl is called with a pointer to this structure the driver
|
||||
will attempt to allocate up to the requested number of buffers and store the
|
||||
actual number allocated and the starting index in the
|
||||
<structfield>count</structfield> and the <structfield>index</structfield> fields
|
||||
respectively. On return <structfield>count</structfield> can be smaller than
|
||||
the number requested. The driver may also increase buffer sizes if required,
|
||||
however, it will not update <structfield>sizeimage</structfield> field values.
|
||||
The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
|
||||
information.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-create-buffers">
|
||||
<title>struct <structname>v4l2_create_buffers</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>The starting buffer index, returned by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>count</structfield></entry>
|
||||
<entry>The number of buffers requested or granted.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-memory;</entry>
|
||||
<entry><structfield>memory</structfield></entry>
|
||||
<entry>Applications set this field to
|
||||
<constant>V4L2_MEMORY_MMAP</constant> or
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-format;</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Filled in by the application, preserved by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>A place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOMEM</errorcode></term>
|
||||
<listitem>
|
||||
<para>No memory to allocate buffers for <link linkend="mmap">memory
|
||||
mapped</link> I/O.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer type (<structfield>type</structfield> field) or the
|
||||
requested I/O method (<structfield>memory</structfield>) is not
|
||||
supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
<refentry id="vidioc-prepare-buf">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_PREPARE_BUF</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_PREPARE_BUF</refname>
|
||||
<refpurpose>Prepare a buffer for I/O</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_buffer *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_PREPARE_BUF</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>Applications can optionally call the
|
||||
<constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
|
||||
to the driver before actually enqueuing it, using the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl, and to prepare it for future I/O.
|
||||
Such preparations may include cache invalidation or cleaning. Performing them
|
||||
in advance saves time during the actual I/O. In case such cache operations are
|
||||
not required, the application can use one of
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant> and
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant> flags to skip the respective
|
||||
step.</para>
|
||||
|
||||
<para>The <structname>v4l2_buffer</structname> structure is
|
||||
specified in <xref linkend="buffer" />.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>File I/O is in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer <structfield>type</structfield> is not
|
||||
supported, or the <structfield>index</structfield> is out of bounds,
|
||||
or no buffers have been allocated yet, or the
|
||||
<structfield>userptr</structfield> or
|
||||
<structfield>length</structfield> are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
||||
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
|
||||
assigned globally at boot time only presently.
|
||||
'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
|
||||
globally at boot time only presently.
|
||||
|
||||
Each io queue has a set of io scheduler tunables associated with it. These
|
||||
tunables control how the io scheduler works. You can find these entries
|
||||
|
|
|
|||
|
|
@ -78,6 +78,16 @@ The device naming scheme is:
|
|||
/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2
|
||||
/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3
|
||||
|
||||
CCISS simple mode support
|
||||
-------------------------
|
||||
|
||||
The "cciss_simple_mode=1" boot parameter may be used to prevent the driver
|
||||
from putting the controller into "performant" mode. The difference is that
|
||||
with simple mode, each command completion requires an interrupt, while with
|
||||
"performant mode" (the default, and ordinarily better performing) it is
|
||||
possible to have multiple command completions indicated by a single
|
||||
interrupt.
|
||||
|
||||
SCSI tape drive and medium changer support
|
||||
------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must
|
|||
move it into a new cgroup (possibly the root cgroup) by writing to the
|
||||
new cgroup's tasks file.
|
||||
|
||||
Note: If the ns cgroup is active, moving a process to another cgroup can
|
||||
fail.
|
||||
Note: Due to some restrictions enforced by some cgroup subsystems, moving
|
||||
a process to another cgroup can fail.
|
||||
|
||||
2.3 Mounting hierarchies by name
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable"
|
|||
|
||||
# The following additional stats are dependent on CONFIG_DEBUG_VM.
|
||||
|
||||
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
|
||||
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for
|
|||
communication.
|
||||
|
||||
There are currently two userspace log implementations that leverage this
|
||||
framework - "clustered_disk" and "clustered_core". These implementations
|
||||
framework - "clustered-disk" and "clustered-core". These implementations
|
||||
provide a cluster-coherent log for shared-storage. Device-mapper mirroring
|
||||
can be used in a shared-storage environment when the cluster log implementations
|
||||
are employed.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,84 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
- Another btree-based caching target posted to dm-devel
|
||||
- Another multi-snapshot target based on a design of Daniel Phillips
|
||||
|
||||
Maintaining these data structures takes a lot of work, so if possible
|
||||
we'd like to reduce the number.
|
||||
|
||||
The persistent-data library is an attempt to provide a re-usable
|
||||
framework for people who want to store metadata in device-mapper
|
||||
targets. It's currently used by the thin-provisioning target and an
|
||||
upcoming hierarchical storage target.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The main documentation is in the header files which can all be found
|
||||
under drivers/md/persistent-data.
|
||||
|
||||
The block manager
|
||||
-----------------
|
||||
|
||||
dm-block-manager.[hc]
|
||||
|
||||
This provides access to the data on disk in fixed sized-blocks. There
|
||||
is a read/write locking interface to prevent concurrent accesses, and
|
||||
keep data that is being used in the cache.
|
||||
|
||||
Clients of persistent-data are unlikely to use this directly.
|
||||
|
||||
The transaction manager
|
||||
-----------------------
|
||||
|
||||
dm-transaction-manager.[hc]
|
||||
|
||||
This restricts access to blocks and enforces copy-on-write semantics.
|
||||
The only way you can get hold of a writable block through the
|
||||
transaction manager is by shadowing an existing block (ie. doing
|
||||
copy-on-write) or allocating a fresh one. Shadowing is elided within
|
||||
the same transaction so performance is reasonable. The commit method
|
||||
ensures that all data is flushed before it writes the superblock.
|
||||
On power failure your metadata will be as it was when last committed.
|
||||
|
||||
The Space Maps
|
||||
--------------
|
||||
|
||||
dm-space-map.h
|
||||
dm-space-map-metadata.[hc]
|
||||
dm-space-map-disk.[hc]
|
||||
|
||||
On-disk data structures that keep track of reference counts of blocks.
|
||||
Also acts as the allocator of new blocks. Currently two
|
||||
implementations: a simpler one for managing blocks on a different
|
||||
device (eg. thinly-provisioned data blocks); and one for managing
|
||||
the metadata space. The latter is complicated by the need to store
|
||||
its own data within the space it's managing.
|
||||
|
||||
The data structures
|
||||
-------------------
|
||||
|
||||
dm-btree.[hc]
|
||||
dm-btree-remove.c
|
||||
dm-btree-spine.c
|
||||
dm-btree-internal.h
|
||||
|
||||
Currently there is only one data structure, a hierarchical btree.
|
||||
There are plans to add more. For example, something with an
|
||||
array-like interface would see a lot of use.
|
||||
|
||||
The btree is 'hierarchical' in that you can define it to be composed
|
||||
of nested btrees, and take multiple keys. For example, the
|
||||
thin-provisioning target uses a btree with two levels of nesting.
|
||||
The first maps a device id to a mapping tree, and that in turn maps a
|
||||
virtual block to a physical block.
|
||||
|
||||
Values stored in the btrees can have arbitrary size. Keys are always
|
||||
64bits, although nesting allows you to use multiple keys.
|
||||
|
|
@ -0,0 +1,285 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
This document descibes a collection of device-mapper targets that
|
||||
between them implement thin-provisioning and snapshots.
|
||||
|
||||
The main highlight of this implementation, compared to the previous
|
||||
implementation of snapshots, is that it allows many virtual devices to
|
||||
be stored on the same data volume. This simplifies administration and
|
||||
allows the sharing of data between volumes, thus reducing disk usage.
|
||||
|
||||
Another significant feature is support for an arbitrary depth of
|
||||
recursive snapshots (snapshots of snapshots of snapshots ...). The
|
||||
previous implementation of snapshots did this by chaining together
|
||||
lookup tables, and so performance was O(depth). This new
|
||||
implementation uses a single data structure to avoid this degradation
|
||||
with depth. Fragmentation may still be an issue, however, in some
|
||||
scenarios.
|
||||
|
||||
Metadata is stored on a separate device from data, giving the
|
||||
administrator some freedom, for example to:
|
||||
|
||||
- Improve metadata resilience by storing metadata on a mirrored volume
|
||||
but data on a non-mirrored one.
|
||||
|
||||
- Improve performance by storing the metadata on SSD.
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
These targets are very much still in the EXPERIMENTAL state. Please
|
||||
do not yet rely on them in production. But do experiment and offer us
|
||||
feedback. Different use cases will have different performance
|
||||
characteristics, for example due to fragmentation of the data volume.
|
||||
|
||||
If you find this software is not performing as expected please mail
|
||||
dm-devel@redhat.com with details and we'll try our best to improve
|
||||
things for you.
|
||||
|
||||
Userspace tools for checking and repairing the metadata are under
|
||||
development.
|
||||
|
||||
Cookbook
|
||||
========
|
||||
|
||||
This section describes some quick recipes for using thin provisioning.
|
||||
They use the dmsetup program to control the device-mapper driver
|
||||
directly. End users will be advised to use a higher-level volume
|
||||
manager such as LVM2 once support has been added.
|
||||
|
||||
Pool device
|
||||
-----------
|
||||
|
||||
The pool device ties together the metadata volume and the data volume.
|
||||
It maps I/O linearly to the data volume and updates the metadata via
|
||||
two mechanisms:
|
||||
|
||||
- Function calls from the thin targets
|
||||
|
||||
- Device-mapper 'messages' from userspace which control the creation of new
|
||||
virtual devices amongst other things.
|
||||
|
||||
Setting up a fresh pool device
|
||||
------------------------------
|
||||
|
||||
Setting up a pool device requires a valid metadata device, and a
|
||||
data device. If you do not have an existing metadata device you can
|
||||
make one by zeroing the first 4k to indicate empty metadata.
|
||||
|
||||
dd if=/dev/zero of=$metadata_dev bs=4096 count=1
|
||||
|
||||
The amount of metadata you need will vary according to how many blocks
|
||||
are shared between thin devices (i.e. through snapshots). If you have
|
||||
less sharing than average you'll need a larger-than-average metadata device.
|
||||
|
||||
As a guide, we suggest you calculate the number of bytes to use in the
|
||||
metadata device as 48 * $data_dev_size / $data_block_size but round it up
|
||||
to 2MB if the answer is smaller. The largest size supported is 16GB.
|
||||
|
||||
If you're creating large numbers of snapshots which are recording large
|
||||
amounts of change, you may need find you need to increase this.
|
||||
|
||||
Reloading a pool table
|
||||
----------------------
|
||||
|
||||
You may reload a pool's table, indeed this is how the pool is resized
|
||||
if it runs out of space. (N.B. While specifying a different metadata
|
||||
device when reloading is not forbidden at the moment, things will go
|
||||
wrong if it does not route I/O to exactly the same on-disk location as
|
||||
previously.)
|
||||
|
||||
Using an existing pool device
|
||||
-----------------------------
|
||||
|
||||
dmsetup create pool \
|
||||
--table "0 20971520 thin-pool $metadata_dev $data_dev \
|
||||
$data_block_size $low_water_mark"
|
||||
|
||||
$data_block_size gives the smallest unit of disk space that can be
|
||||
allocated at a time expressed in units of 512-byte sectors. People
|
||||
primarily interested in thin provisioning may want to use a value such
|
||||
as 1024 (512KB). People doing lots of snapshotting may want a smaller value
|
||||
such as 128 (64KB). If you are not zeroing newly-allocated data,
|
||||
a larger $data_block_size in the region of 256000 (128MB) is suggested.
|
||||
$data_block_size must be the same for the lifetime of the
|
||||
metadata device.
|
||||
|
||||
$low_water_mark is expressed in blocks of size $data_block_size. If
|
||||
free space on the data device drops below this level then a dm event
|
||||
will be triggered which a userspace daemon should catch allowing it to
|
||||
extend the pool device. Only one such event will be sent.
|
||||
Resuming a device with a new table itself triggers an event so the
|
||||
userspace daemon can use this to detect a situation where a new table
|
||||
already exceeds the threshold.
|
||||
|
||||
Thin provisioning
|
||||
-----------------
|
||||
|
||||
i) Creating a new thinly-provisioned volume.
|
||||
|
||||
To create a new thinly- provisioned volume you must send a message to an
|
||||
active pool device, /dev/mapper/pool in this example.
|
||||
|
||||
dmsetup message /dev/mapper/pool 0 "create_thin 0"
|
||||
|
||||
Here '0' is an identifier for the volume, a 24-bit number. It's up
|
||||
to the caller to allocate and manage these identifiers. If the
|
||||
identifier is already in use, the message will fail with -EEXIST.
|
||||
|
||||
ii) Using a thinly-provisioned volume.
|
||||
|
||||
Thinly-provisioned volumes are activated using the 'thin' target:
|
||||
|
||||
dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0"
|
||||
|
||||
The last parameter is the identifier for the thinp device.
|
||||
|
||||
Internal snapshots
|
||||
------------------
|
||||
|
||||
i) Creating an internal snapshot.
|
||||
|
||||
Snapshots are created with another message to the pool.
|
||||
|
||||
N.B. If the origin device that you wish to snapshot is active, you
|
||||
must suspend it before creating the snapshot to avoid corruption.
|
||||
This is NOT enforced at the moment, so please be careful!
|
||||
|
||||
dmsetup suspend /dev/mapper/thin
|
||||
dmsetup message /dev/mapper/pool 0 "create_snap 1 0"
|
||||
dmsetup resume /dev/mapper/thin
|
||||
|
||||
Here '1' is the identifier for the volume, a 24-bit number. '0' is the
|
||||
identifier for the origin device.
|
||||
|
||||
ii) Using an internal snapshot.
|
||||
|
||||
Once created, the user doesn't have to worry about any connection
|
||||
between the origin and the snapshot. Indeed the snapshot is no
|
||||
different from any other thinly-provisioned device and can be
|
||||
snapshotted itself via the same method. It's perfectly legal to
|
||||
have only one of them active, and there's no ordering requirement on
|
||||
activating or removing them both. (This differs from conventional
|
||||
device-mapper snapshots.)
|
||||
|
||||
Activate it exactly the same way as any other thinly-provisioned volume:
|
||||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
||||
|
||||
Deactivation
|
||||
------------
|
||||
|
||||
All devices using a pool must be deactivated before the pool itself
|
||||
can be.
|
||||
|
||||
dmsetup remove thin
|
||||
dmsetup remove snap
|
||||
dmsetup remove pool
|
||||
|
||||
Reference
|
||||
=========
|
||||
|
||||
'thin-pool' target
|
||||
------------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin-pool <metadata dev> <data dev> <data block size (sectors)> \
|
||||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||
|
||||
Optional feature arguments:
|
||||
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
||||
|
||||
ii) Status
|
||||
|
||||
<transaction id> <used metadata blocks>/<total metadata blocks>
|
||||
<used data blocks>/<total data blocks> <held metadata root>
|
||||
|
||||
|
||||
transaction id:
|
||||
A 64-bit number used by userspace to help synchronise with metadata
|
||||
from volume managers.
|
||||
|
||||
used data blocks / total data blocks
|
||||
If the number of free blocks drops below the pool's low water mark a
|
||||
dm event will be sent to userspace. This event is edge-triggered and
|
||||
it will occur only once after each resume so volume manager writers
|
||||
should register for the event and then check the target's status.
|
||||
|
||||
held metadata root:
|
||||
The location, in sectors, of the metadata root that has been
|
||||
'held' for userspace read access. '-' indicates there is no
|
||||
held root. This feature is not yet implemented so '-' is
|
||||
always returned.
|
||||
|
||||
iii) Messages
|
||||
|
||||
create_thin <dev id>
|
||||
|
||||
Create a new thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
|
||||
create_snap <dev id> <origin id>
|
||||
|
||||
Create a new snapshot of another thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
<origin id> is the identifier of the thinly-provisioned device
|
||||
of which the new device will be a snapshot.
|
||||
|
||||
delete <dev id>
|
||||
|
||||
Deletes a thin device. Irreversible.
|
||||
|
||||
trim <dev id> <new size in sectors>
|
||||
|
||||
Delete mappings from the end of a thin device. Irreversible.
|
||||
You might want to use this if you're reducing the size of
|
||||
your thinly-provisioned device. In many cases, due to the
|
||||
sharing of blocks between devices, it is not possible to
|
||||
determine in advance how much space 'trim' will release. (In
|
||||
future a userspace tool might be able to perform this
|
||||
calculation.)
|
||||
|
||||
set_transaction_id <current id> <new id>
|
||||
|
||||
Userland volume managers, such as LVM, need a way to
|
||||
synchronise their external metadata with the internal metadata of the
|
||||
pool target. The thin-pool target offers to store an
|
||||
arbitrary 64-bit transaction id and return it on the target's
|
||||
status line. To avoid races you must provide what you think
|
||||
the current transaction id is when you change it with this
|
||||
compare-and-swap message.
|
||||
|
||||
'thin' target
|
||||
-------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin <pool dev> <dev id>
|
||||
|
||||
pool dev:
|
||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
||||
|
||||
dev id:
|
||||
the internal device identifier of the device to be
|
||||
activated.
|
||||
|
||||
The pool doesn't store any size against the thin devices. If you
|
||||
load a thin target that is smaller than you've been using previously,
|
||||
then you'll have no access to blocks mapped beyond the end. If you
|
||||
load a target that is bigger than before, then extra blocks will be
|
||||
provisioned as and when needed.
|
||||
|
||||
If you wish to reduce the size of your thin device and potentially
|
||||
regain some space then send the 'trim' message to the pool.
|
||||
|
||||
ii) Status
|
||||
|
||||
<nr mapped sectors> <highest mapped sector>
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
* Calxeda SATA Controller
|
||||
|
||||
SATA nodes are defined to describe on-chip Serial ATA controllers.
|
||||
Each SATA controller should have its own node.
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, contains "calxeda,hb-ahci"
|
||||
- interrupts : <interrupt mapping for SATA IRQ>
|
||||
- reg : <registers mapping>
|
||||
|
||||
Example:
|
||||
sata@ffe08000 {
|
||||
compatible = "calxeda,hb-ahci";
|
||||
reg = <0xffe08000 0x1000>;
|
||||
interrupts = <115>;
|
||||
};
|
||||
|
||||
|
|
@ -1,3 +1,8 @@
|
|||
Freescale Reference Board Bindings
|
||||
|
||||
This document describes device tree bindings for various devices that
|
||||
exist on some Freescale reference boards.
|
||||
|
||||
* Board Control and Status (BCSR)
|
||||
|
||||
Required properties:
|
||||
|
|
@ -12,25 +17,26 @@ Example:
|
|||
reg = <f8000000 8000>;
|
||||
};
|
||||
|
||||
* Freescale on board FPGA
|
||||
* 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 length of the FPPGA register
|
||||
set.
|
||||
- compatible: should be a board-specific string followed by a string
|
||||
indicating the type of FPGA. Example:
|
||||
"fsl,<board>-fpga", "fsl,fpga-pixis"
|
||||
- reg: should contain the address and the length of the FPGA register set.
|
||||
- interrupt-parent: should specify phandle for the interrupt controller.
|
||||
- interrupts : should specify event (wakeup) IRQ.
|
||||
- interrupts: should specify event (wakeup) IRQ.
|
||||
|
||||
Example (MPC8610HPCD):
|
||||
Example (P1022DS):
|
||||
|
||||
board-control@e8000000 {
|
||||
compatible = "fsl,fpga-pixis";
|
||||
reg = <0xe8000000 32>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8>;
|
||||
};
|
||||
board-control@3,0 {
|
||||
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
|
||||
reg = <3 0 0x30>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8 0 0>;
|
||||
};
|
||||
|
||||
* Freescale BCSR GPIO banks
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,395 @@
|
|||
===================================================================
|
||||
Debug Control and Status Register (DCSR) Binding
|
||||
Copyright 2011 Freescale Semiconductor Inc.
|
||||
|
||||
NOTE: The bindings described in this document are preliminary and subject
|
||||
to change. Some of the compatible strings that contain only generic names
|
||||
may turn out to be inappropriate, or need additional properties to describe
|
||||
the integration of the block with the rest of the chip.
|
||||
|
||||
=====================================================================
|
||||
Debug Control and Status Register Memory Map
|
||||
|
||||
Description
|
||||
|
||||
This node defines the base address and range for the
|
||||
defined DCSR Memory Map. Child nodes will describe the individual
|
||||
debug blocks defined within this memory space.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr" and "simple-bus".
|
||||
The DCSR space exists in the memory-mapped bus.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
or representing physical addresses in child nodes.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
or representing the size of physical addresses in
|
||||
child nodes.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the DCSR space.
|
||||
|
||||
EXAMPLE
|
||||
dcsr: dcsr@f00000000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,dcsr", "simple-bus";
|
||||
ranges = <0x00000000 0xf 0x00000000 0x01008000>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Event Processing Unit
|
||||
|
||||
This node represents the region of DCSR space allocated to the EPU
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-epu"
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by the EPU.
|
||||
The value of the interrupts property consists of three
|
||||
interrupt specifiers. The format of the specifier is defined
|
||||
by the binding document describing the node's interrupt parent.
|
||||
|
||||
The EPU counters can be configured to assert the performance
|
||||
monitor interrupt signal based on either counter overflow or value
|
||||
match. Which counter asserted the interrupt is captured in an EPU
|
||||
Counter Interrupt Status Register (EPCPUISR).
|
||||
|
||||
The EPU unit can also be configured to assert either or both of
|
||||
two interrupt signals based on debug event sources within the SoC.
|
||||
The interrupt signals are epu_xt_int0 and epu_xt_int1.
|
||||
Which event source asserted the interrupt is captured in an EPU
|
||||
Interrupt Status Register (EPISR0,EPISR1).
|
||||
|
||||
Interrupt numbers are lised in order (perfmon, event0, event1).
|
||||
|
||||
- interrupt-parent
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: A single <phandle> value that points
|
||||
to the interrupt parent to which the child domain
|
||||
is being mapped. Value must be "&mpic"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-epu@0 {
|
||||
compatible = "fsl,dcsr-epu";
|
||||
interrupts = <52 2 0 0
|
||||
84 2 0 0
|
||||
85 2 0 0>;
|
||||
interrupt-parent = <&mpic>;
|
||||
reg = <0x0 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Port Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to the NPC
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-npc"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
The Nexus Port controller occupies two regions in the DCSR space
|
||||
with distinct functionality.
|
||||
|
||||
The first register range describes the Nexus Port Controller
|
||||
control and status registers.
|
||||
|
||||
The second register range describes the Nexus Port Controller
|
||||
internal trace buffer. The NPC trace buffer is a small memory buffer
|
||||
which stages the nexus trace data for transmission via the Aurora port
|
||||
or to a DDR based trace buffer. In some configurations the NPC trace
|
||||
buffer can be the only trace buffer used.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
dcsr-npc {
|
||||
compatible = "fsl,dcsr-npc";
|
||||
reg = <0x1000 0x1000 0x1000000 0x8000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Concentrator
|
||||
|
||||
This node represents the region of DCSR space allocated to the NXC
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-nxc"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-nxc@2000 {
|
||||
compatible = "fsl,dcsr-nxc";
|
||||
reg = <0x2000 0x1000>;
|
||||
};
|
||||
=======================================================================
|
||||
CoreNet Debug Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the CoreNet Debug controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-corenet"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
The CoreNet Debug controller occupies two regions in the DCSR space
|
||||
with distinct functionality.
|
||||
|
||||
The first register range describes the CoreNet Debug Controller
|
||||
functionalty to perform transaction and transaction attribute matches.
|
||||
|
||||
The second register range describes the CoreNet Debug Controller
|
||||
functionalty to trigger event notifications and debug traces.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-corenet {
|
||||
compatible = "fsl,dcsr-corenet";
|
||||
reg = <0x8000 0x1000 0xB0000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Data Path Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the DPAA Debug Controller. This controller controls debug configuration
|
||||
for the QMAN and FMAN blocks.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-dpaa" in addition to the
|
||||
generic compatible string "fsl,dcsr-dpaa".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-dpaa@9000 {
|
||||
compatible = "fsl,p4080-dcsr-dpaa", "fsl,dcsr-dpaa";
|
||||
reg = <0x9000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
OCeaN Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the OCN Debug Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-ocn" in addition to the
|
||||
generic compatible string "fsl,dcsr-ocn".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-ocn@11000 {
|
||||
compatible = "fsl,p4080-dcsr-ocn", "fsl,dcsr-ocn";
|
||||
reg = <0x11000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
DDR Controller Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the OCN Debug Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-ddr"
|
||||
|
||||
- dev-handle
|
||||
Usage: required
|
||||
Definition: A phandle to associate this debug node with its
|
||||
component controller.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-ddr@12000 {
|
||||
compatible = "fsl,dcsr-ddr";
|
||||
dev-handle = <&ddr1>;
|
||||
reg = <0x12000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Aurora Link Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the NAL Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-nal" in addition to the
|
||||
generic compatible string "fsl,dcsr-nal".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-nal@18000 {
|
||||
compatible = "fsl,p4080-dcsr-nal", "fsl,dcsr-nal";
|
||||
reg = <0x18000 0x1000>;
|
||||
};
|
||||
|
||||
|
||||
=======================================================================
|
||||
Run Control and Power Management
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the RCPM Debug Controller. This functionlity is limited to the
|
||||
control the debug operations of the SoC and cores.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-rcpm" in addition to the
|
||||
generic compatible string "fsl,dcsr-rcpm".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-rcpm@22000 {
|
||||
compatible = "fsl,p4080-dcsr-rcpm", "fsl,dcsr-rcpm";
|
||||
reg = <0x22000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Core Service Bridge Proxy
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the Core Service Bridge Proxies.
|
||||
There is one Core Service Bridge Proxy device for each CPU in the system.
|
||||
This functionlity provides access to the debug operations of the CPU.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the cpu
|
||||
of the form "fsl,dcsr-<cpu>-sb-proxy" in addition to the
|
||||
generic compatible string "fsl,dcsr-cpu-sb-proxy".
|
||||
|
||||
- cpu-handle
|
||||
Usage: required
|
||||
Definition: A phandle to associate this debug node with its cpu.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-cpu-sb-proxy@40000 {
|
||||
compatible = "fsl,dcsr-e500mc-sb-proxy",
|
||||
"fsl,dcsr-cpu-sb-proxy";
|
||||
cpu-handle = <&cpu0>;
|
||||
reg = <0x40000 0x1000>;
|
||||
};
|
||||
dcsr-cpu-sb-proxy@41000 {
|
||||
compatible = "fsl,dcsr-e500mc-sb-proxy",
|
||||
"fsl,dcsr-cpu-sb-proxy";
|
||||
cpu-handle = <&cpu1>;
|
||||
reg = <0x41000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
|
|
@ -25,6 +25,16 @@ Required properties:
|
|||
are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed
|
||||
to MPIC.
|
||||
|
||||
Optional properties:
|
||||
- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register
|
||||
is used for MSI messaging. The address of MSIIR in PCI address space is
|
||||
the MSI message address.
|
||||
|
||||
This property may be used in virtualized environments where the hypervisor
|
||||
has created an alternate mapping for the MSIR block. See below for an
|
||||
explanation.
|
||||
|
||||
|
||||
Example:
|
||||
msi@41600 {
|
||||
compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
|
||||
|
|
@ -41,3 +51,35 @@ Example:
|
|||
0xe7 0>;
|
||||
interrupt-parent = <&mpic>;
|
||||
};
|
||||
|
||||
The Freescale hypervisor and msi-address-64
|
||||
-------------------------------------------
|
||||
Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
|
||||
Freescale MSI driver calculates the address of MSIIR (in the MSI register
|
||||
block) and sets that address as the MSI message address.
|
||||
|
||||
In a virtualized environment, the hypervisor may need to create an IOMMU
|
||||
mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
|
||||
because of hardware limitations of the Peripheral Access Management Unit
|
||||
(PAMU), which is currently the only IOMMU that the hypervisor supports.
|
||||
The ATMU is programmed with the guest physical address, and the PAMU
|
||||
intercepts transactions and reroutes them to the true physical address.
|
||||
|
||||
In the PAMU, each PCI controller is given only one primary window. The
|
||||
PAMU restricts DMA operations so that they can only occur within a window.
|
||||
Because PCI devices must be able to DMA to memory, the primary window must
|
||||
be used to cover all of the guest's memory space.
|
||||
|
||||
PAMU primary windows can be divided into 256 subwindows, and each
|
||||
subwindow can have its own address mapping ("guest physical" to "true
|
||||
physical"). However, each subwindow has to have the same alignment, which
|
||||
means they cannot be located at just any address. Because of these
|
||||
restrictions, it is usually impossible to create a 4KB subwindow that
|
||||
covers MSIIR where it's normally located.
|
||||
|
||||
Therefore, the hypervisor has to create a subwindow inside the same
|
||||
primary window used for memory, but mapped to the MSIR block (where MSIIR
|
||||
lives). The first subwindow after the end of guest memory is used for
|
||||
this. The address specified in the msi-address-64 property is the PCI
|
||||
address of MSIIR. The hypervisor configures the PAMU to map that address to
|
||||
the true physical address of MSIIR.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
* virtio memory mapped device
|
||||
|
||||
See http://ozlabs.org/~rusty/virtio-spec/ for more details.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "virtio,mmio" compatibility string
|
||||
- reg: control registers base address and size including configuration space
|
||||
- interrupts: interrupt generated by the device
|
||||
|
||||
Example:
|
||||
|
||||
virtio_block@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <41>;
|
||||
}
|
||||
|
|
@ -133,41 +133,6 @@ Who: Pavel Machek <pavel@ucw.cz>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: sys_sysctl
|
||||
When: September 2010
|
||||
Option: CONFIG_SYSCTL_SYSCALL
|
||||
Why: The same information is available in a more convenient from
|
||||
/proc/sys, and none of the sysctl variables appear to be
|
||||
important performance wise.
|
||||
|
||||
Binary sysctls are a long standing source of subtle kernel
|
||||
bugs and security issues.
|
||||
|
||||
When I looked several months ago all I could find after
|
||||
searching several distributions were 5 user space programs and
|
||||
glibc (which falls back to /proc/sys) using this syscall.
|
||||
|
||||
The man page for sysctl(2) documents it as unusable for user
|
||||
space programs.
|
||||
|
||||
sysctl(2) is not generally ABI compatible to a 32bit user
|
||||
space application on a 64bit and a 32bit kernel.
|
||||
|
||||
For the last several months the policy has been no new binary
|
||||
sysctls and no one has put forward an argument to use them.
|
||||
|
||||
Binary sysctls issues seem to keep happening appearing so
|
||||
properly deprecating them (with a warning to user space) and a
|
||||
2 year grace warning period will mean eventually we can kill
|
||||
them and end the pain.
|
||||
|
||||
In the mean time individual binary sysctls can be dealt with
|
||||
in a piecewise fashion.
|
||||
|
||||
Who: Eric Biederman <ebiederm@xmission.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ d_hash no no no maybe
|
|||
d_compare: yes no no maybe
|
||||
d_delete: no yes no no
|
||||
d_release: no no yes no
|
||||
d_prune: no yes no no
|
||||
d_iput: no no yes no
|
||||
d_dname: no no no no
|
||||
d_automount: no no yes no
|
||||
|
|
|
|||
|
|
@ -73,14 +73,6 @@ nobarrier (*) This also requires an IO stack which can support
|
|||
also be used to enable or disable barriers, for
|
||||
consistency with other ext3 mount options.
|
||||
|
||||
orlov (*) This enables the new Orlov block allocator. It is
|
||||
enabled by default.
|
||||
|
||||
oldalloc This disables the Orlov block allocator and enables
|
||||
the old block allocator. Orlov should have better
|
||||
performance - we'd like to get some feedback if it's
|
||||
the contrary for you.
|
||||
|
||||
user_xattr Enables Extended User Attributes. Additionally, you
|
||||
need to have extended attribute support enabled in the
|
||||
kernel configuration (CONFIG_EXT3_FS_XATTR). See the
|
||||
|
|
|
|||
|
|
@ -160,7 +160,9 @@ noload if the filesystem was not unmounted cleanly,
|
|||
lead to any number of problems.
|
||||
|
||||
data=journal All data are committed into the journal prior to being
|
||||
written into the main file system.
|
||||
written into the main file system. Enabling
|
||||
this mode will disable delayed allocation and
|
||||
O_DIRECT support.
|
||||
|
||||
data=ordered (*) All data are forced directly out to the main file
|
||||
system prior to its metadata being committed to the
|
||||
|
|
@ -201,30 +203,19 @@ inode_readahead_blks=n This tuning parameter controls the maximum
|
|||
table readahead algorithm will pre-read into
|
||||
the buffer cache. The default value is 32 blocks.
|
||||
|
||||
orlov (*) This enables the new Orlov block allocator. It is
|
||||
enabled by default.
|
||||
|
||||
oldalloc This disables the Orlov block allocator and enables
|
||||
the old block allocator. Orlov should have better
|
||||
performance - we'd like to get some feedback if it's
|
||||
the contrary for you.
|
||||
|
||||
user_xattr Enables Extended User Attributes. Additionally, you
|
||||
need to have extended attribute support enabled in the
|
||||
kernel configuration (CONFIG_EXT4_FS_XATTR). See the
|
||||
attr(5) manual page and http://acl.bestbits.at/ to
|
||||
learn more about extended attributes.
|
||||
|
||||
nouser_xattr Disables Extended User Attributes.
|
||||
|
||||
acl Enables POSIX Access Control Lists support.
|
||||
Additionally, you need to have ACL support enabled in
|
||||
the kernel configuration (CONFIG_EXT4_FS_POSIX_ACL).
|
||||
See the acl(5) manual page and http://acl.bestbits.at/
|
||||
for more information.
|
||||
nouser_xattr Disables Extended User Attributes. If you have extended
|
||||
attribute support enabled in the kernel configuration
|
||||
(CONFIG_EXT4_FS_XATTR), extended attribute support
|
||||
is enabled by default on mount. See the attr(5) manual
|
||||
page and http://acl.bestbits.at/ for more information
|
||||
about extended attributes.
|
||||
|
||||
noacl This option disables POSIX Access Control List
|
||||
support.
|
||||
support. If ACL support is enabled in the kernel
|
||||
configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL is
|
||||
enabled by default on mount. See the acl(5) manual
|
||||
page and http://acl.bestbits.at/ for more information
|
||||
about acl.
|
||||
|
||||
bsddf (*) Make 'df' act like BSD.
|
||||
minixdf Make 'df' act like Minix.
|
||||
|
|
@ -419,8 +410,8 @@ written to the journal first, and then to its final location.
|
|||
In the event of a crash, the journal can be replayed, bringing both data and
|
||||
metadata into a consistent state. This mode is the slowest except when data
|
||||
needs to be read from and written to disk at the same time where it
|
||||
outperforms all others modes. Currently ext4 does not have delayed
|
||||
allocation support if this data journalling mode is selected.
|
||||
outperforms all others modes. Enabling this mode will disable delayed
|
||||
allocation and O_DIRECT support.
|
||||
|
||||
/proc entries
|
||||
=============
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
Note: This filesystem doesn't have a maintainer.
|
||||
|
||||
Macintosh HFS Filesystem for Linux
|
||||
==================================
|
||||
|
|
@ -76,8 +77,6 @@ hformat that can be used to create HFS filesystem. See
|
|||
Credits
|
||||
=======
|
||||
|
||||
The HFS drivers was written by Paul H. Hargrovea (hargrove@sccm.Stanford.EDU)
|
||||
and is now maintained by Roman Zippel (roman@ardistech.com) at Ardis
|
||||
Technologies.
|
||||
Roman rewrote large parts of the code and brought in btree routines derived
|
||||
from Brad Boyer's hfsplus driver (also maintained by Roman now).
|
||||
The HFS drivers was written by Paul H. Hargrovea (hargrove@sccm.Stanford.EDU).
|
||||
Roman Zippel (roman@ardistech.com) rewrote large parts of the code and brought
|
||||
in btree routines derived from Brad Boyer's hfsplus driver.
|
||||
|
|
|
|||
|
|
@ -194,7 +194,8 @@ associated with the inotify_handle, and on which events are queued.
|
|||
Each watch is associated with an inotify_watch structure. Watches are chained
|
||||
off of each associated inotify_handle and each associated inode.
|
||||
|
||||
See fs/inotify.c and fs/inotify_user.c for the locking and lifetime rules.
|
||||
See fs/notify/inotify/inotify_fsnotify.c and fs/notify/inotify/inotify_user.c
|
||||
for the locking and lifetime rules.
|
||||
|
||||
|
||||
(vi) Rationale
|
||||
|
|
|
|||
|
|
@ -14,6 +14,10 @@ Supported chips:
|
|||
Prefix: 'w83627dhg'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: not available
|
||||
* Winbond W83627UHG
|
||||
Prefix: 'w83627uhg'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: available from www.nuvoton.com
|
||||
* Winbond W83667HG
|
||||
Prefix: 'w83667hg'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
|
|
@ -42,14 +46,13 @@ Description
|
|||
-----------
|
||||
|
||||
This driver implements support for the Winbond W83627EHF, W83627EHG,
|
||||
W83627DHG, W83627DHG-P, W83667HG, W83667HG-B, W83667HG-I (NCT6775F),
|
||||
and NCT6776F super I/O chips. We will refer to them collectively as
|
||||
Winbond chips.
|
||||
W83627DHG, W83627DHG-P, W83627UHG, W83667HG, W83667HG-B, W83667HG-I
|
||||
(NCT6775F), and NCT6776F super I/O chips. We will refer to them collectively
|
||||
as Winbond chips.
|
||||
|
||||
The chips implement three temperature sensors (up to four for 667HG-B, and nine
|
||||
for NCT6775F and NCT6776F), five fan rotation speed sensors, ten analog voltage
|
||||
sensors (only nine for the 627DHG), one VID (6 pins for the 627EHF/EHG, 8 pins
|
||||
for the 627DHG and 667HG), alarms with beep warnings (control unimplemented),
|
||||
The chips implement 2 to 4 temperature sensors (9 for NCT6775F and NCT6776F),
|
||||
2 to 5 fan rotation speed sensors, 8 to 10 analog voltage sensors, one VID
|
||||
(except for 627UHG), alarms with beep warnings (control unimplemented),
|
||||
and some automatic fan regulation strategies (plus manual fan control mode).
|
||||
|
||||
The temperature sensor sources on W82677HG-B, NCT6775F, and NCT6776F are
|
||||
|
|
@ -86,17 +89,16 @@ follows:
|
|||
|
||||
temp1 -> pwm1
|
||||
temp2 -> pwm2
|
||||
temp3 -> pwm3
|
||||
temp3 -> pwm3 (not on 627UHG)
|
||||
prog -> pwm4 (not on 667HG and 667HG-B; the programmable setting is not
|
||||
supported by the driver)
|
||||
|
||||
/sys files
|
||||
----------
|
||||
|
||||
name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG,
|
||||
it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg",
|
||||
for the W83667HG and W83667HG-B it is set to "w83667hg", for NCT6775F it
|
||||
is set to "nct6775", and for NCT6776F it is set to "nct6776".
|
||||
name - this is a standard hwmon device entry, it contains the name of
|
||||
the device (see the prefix in the list of supported devices at
|
||||
the top of this file)
|
||||
|
||||
pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
|
||||
0 (stop) to 255 (full)
|
||||
|
|
|
|||
|
|
@ -39,23 +39,20 @@ independent, drivers.
|
|||
in case an unused hwspinlock isn't available. Users of this
|
||||
API will usually want to communicate the lock's id to the remote core
|
||||
before it can be used to achieve synchronization.
|
||||
Can be called from an atomic context (this function will not sleep) but
|
||||
not from within interrupt context.
|
||||
Should be called from a process context (might sleep).
|
||||
|
||||
struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
|
||||
- assign a specific hwspinlock id and return its address, or NULL
|
||||
if that hwspinlock is already in use. Usually board code will
|
||||
be calling this function in order to reserve specific hwspinlock
|
||||
ids for predefined purposes.
|
||||
Can be called from an atomic context (this function will not sleep) but
|
||||
not from within interrupt context.
|
||||
Should be called from a process context (might sleep).
|
||||
|
||||
int hwspin_lock_free(struct hwspinlock *hwlock);
|
||||
- free a previously-assigned hwspinlock; returns 0 on success, or an
|
||||
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
|
||||
is already free).
|
||||
Can be called from an atomic context (this function will not sleep) but
|
||||
not from within interrupt context.
|
||||
Should be called from a process context (might sleep).
|
||||
|
||||
int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int timeout);
|
||||
- lock a previously-assigned hwspinlock with a timeout limit (specified in
|
||||
|
|
@ -230,45 +227,62 @@ int hwspinlock_example2(void)
|
|||
|
||||
4. API for implementors
|
||||
|
||||
int hwspin_lock_register(struct hwspinlock *hwlock);
|
||||
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
|
||||
const struct hwspinlock_ops *ops, int base_id, int num_locks);
|
||||
- to be called from the underlying platform-specific implementation, in
|
||||
order to register a new hwspinlock instance. Can be called from an atomic
|
||||
context (this function will not sleep) but not from within interrupt
|
||||
context. Returns 0 on success, or appropriate error code on failure.
|
||||
order to register a new hwspinlock device (which is usually a bank of
|
||||
numerous locks). Should be called from a process context (this function
|
||||
might sleep).
|
||||
Returns 0 on success, or appropriate error code on failure.
|
||||
|
||||
struct hwspinlock *hwspin_lock_unregister(unsigned int id);
|
||||
int hwspin_lock_unregister(struct hwspinlock_device *bank);
|
||||
- to be called from the underlying vendor-specific implementation, in order
|
||||
to unregister an existing (and unused) hwspinlock instance.
|
||||
Can be called from an atomic context (will not sleep) but not from
|
||||
within interrupt context.
|
||||
to unregister an hwspinlock device (which is usually a bank of numerous
|
||||
locks).
|
||||
Should be called from a process context (this function might sleep).
|
||||
Returns the address of hwspinlock on success, or NULL on error (e.g.
|
||||
if the hwspinlock is sill in use).
|
||||
|
||||
5. struct hwspinlock
|
||||
5. Important structs
|
||||
|
||||
This struct represents an hwspinlock instance. It is registered by the
|
||||
underlying hwspinlock implementation using the hwspin_lock_register() API.
|
||||
struct hwspinlock_device is a device which usually contains a bank
|
||||
of hardware locks. It is registered by the underlying hwspinlock
|
||||
implementation using the hwspin_lock_register() API.
|
||||
|
||||
/**
|
||||
* struct hwspinlock - vendor-specific hwspinlock implementation
|
||||
*
|
||||
* @dev: underlying device, will be used with runtime PM api
|
||||
* @ops: vendor-specific hwspinlock handlers
|
||||
* @id: a global, unique, system-wide, index of the lock.
|
||||
* @lock: initialized and used by hwspinlock core
|
||||
* @owner: underlying implementation module, used to maintain module ref count
|
||||
* struct hwspinlock_device - a device which usually spans numerous hwspinlocks
|
||||
* @dev: underlying device, will be used to invoke runtime PM api
|
||||
* @ops: platform-specific hwspinlock handlers
|
||||
* @base_id: id index of the first lock in this device
|
||||
* @num_locks: number of locks in this device
|
||||
* @lock: dynamically allocated array of 'struct hwspinlock'
|
||||
*/
|
||||
struct hwspinlock {
|
||||
struct hwspinlock_device {
|
||||
struct device *dev;
|
||||
const struct hwspinlock_ops *ops;
|
||||
int id;
|
||||
spinlock_t lock;
|
||||
struct module *owner;
|
||||
int base_id;
|
||||
int num_locks;
|
||||
struct hwspinlock lock[0];
|
||||
};
|
||||
|
||||
The underlying implementation is responsible to assign the dev, ops, id and
|
||||
owner members. The lock member, OTOH, is initialized and used by the hwspinlock
|
||||
core.
|
||||
struct hwspinlock_device contains an array of hwspinlock structs, each
|
||||
of which represents a single hardware lock:
|
||||
|
||||
/**
|
||||
* struct hwspinlock - this struct represents a single hwspinlock instance
|
||||
* @bank: the hwspinlock_device structure which owns this lock
|
||||
* @lock: initialized and used by hwspinlock core
|
||||
* @priv: private data, owned by the underlying platform-specific hwspinlock drv
|
||||
*/
|
||||
struct hwspinlock {
|
||||
struct hwspinlock_device *bank;
|
||||
spinlock_t lock;
|
||||
void *priv;
|
||||
};
|
||||
|
||||
When registering a bank of locks, the hwspinlock driver only needs to
|
||||
set the priv members of the locks. The rest of the members are set and
|
||||
initialized by the hwspinlock core itself.
|
||||
|
||||
6. Implementation callbacks
|
||||
|
||||
|
|
|
|||
|
|
@ -411,9 +411,9 @@ event code Key Notes
|
|||
|
||||
0x1004 0x03 FN+F4 Sleep button (ACPI sleep button
|
||||
semantics, i.e. sleep-to-RAM).
|
||||
It is always generate some kind
|
||||
It always generates some kind
|
||||
of event, either the hot key
|
||||
event or a ACPI sleep button
|
||||
event or an ACPI sleep button
|
||||
event. The firmware may
|
||||
refuse to generate further FN+F4
|
||||
key presses until a S3 or S4 ACPI
|
||||
|
|
|
|||
|
|
@ -61,8 +61,8 @@ Hardware accelerated blink of LEDs
|
|||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||
however, it is better to use use the API function led_blink_set(),
|
||||
as it will check and implement software fallback if necessary.
|
||||
however, it is better to use the API function led_blink_set(), as it
|
||||
will check and implement software fallback if necessary.
|
||||
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
|
|
|
|||
|
|
@ -15,6 +15,23 @@ amemthresh - INTEGER
|
|||
enabled and the variable is automatically set to 2, otherwise
|
||||
the strategy is disabled and the variable is set to 1.
|
||||
|
||||
conntrack - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
|
||||
If set, maintain connection tracking entries for
|
||||
connections handled by IPVS.
|
||||
|
||||
This should be enabled if connections handled by IPVS are to be
|
||||
also handled by stateful firewall rules. That is, iptables rules
|
||||
that make use of connection tracking. It is a performance
|
||||
optimisation to disable this setting otherwise.
|
||||
|
||||
Connections handled by the IPVS FTP application module
|
||||
will have connection tracking entries regardless of this setting.
|
||||
|
||||
Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
|
||||
|
||||
cache_bypass - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
|
|
@ -39,7 +56,7 @@ debug_level - INTEGER
|
|||
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
|
||||
12 or more - packet traversal
|
||||
|
||||
Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG
|
||||
Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
|
||||
|
||||
Higher debugging levels include the messages for lower debugging
|
||||
levels, so setting debug level 2, includes level 0, 1 and 2
|
||||
|
|
@ -123,13 +140,11 @@ nat_icmp_send - BOOLEAN
|
|||
secure_tcp - INTEGER
|
||||
0 - disabled (default)
|
||||
|
||||
The secure_tcp defense is to use a more complicated state
|
||||
transition table and some possible short timeouts of each
|
||||
state. In the VS/NAT, it delays the entering the ESTABLISHED
|
||||
until the real server starts to send data and ACK packet
|
||||
(after 3-way handshake).
|
||||
The secure_tcp defense is to use a more complicated TCP state
|
||||
transition table. For VS/NAT, it also delays entering the
|
||||
TCP ESTABLISHED state until the three way handshake is completed.
|
||||
|
||||
The value definition is the same as that of drop_entry or
|
||||
The value definition is the same as that of drop_entry and
|
||||
drop_packet.
|
||||
|
||||
sync_threshold - INTEGER
|
||||
|
|
@ -141,3 +156,36 @@ sync_threshold - INTEGER
|
|||
synchronized, every time the number of its incoming packets
|
||||
modulus 50 equals the threshold. The range of the threshold is
|
||||
from 0 to 49.
|
||||
|
||||
snat_reroute - BOOLEAN
|
||||
0 - disabled
|
||||
not 0 - enabled (default)
|
||||
|
||||
If enabled, recalculate the route of SNATed packets from
|
||||
realservers so that they are routed as if they originate from the
|
||||
director. Otherwise they are routed as if they are forwarded by the
|
||||
director.
|
||||
|
||||
If policy routing is in effect then it is possible that the route
|
||||
of a packet originating from a director is routed differently to a
|
||||
packet being forwarded by the director.
|
||||
|
||||
If policy routing is not in effect then the recalculated route will
|
||||
always be the same as the original route so it is an optimisation
|
||||
to disable snat_reroute and avoid the recalculation.
|
||||
|
||||
sync_version - INTEGER
|
||||
default 1
|
||||
|
||||
The version of the synchronisation protocol used when sending
|
||||
synchronisation messages.
|
||||
|
||||
0 selects the original synchronisation protocol (version 0). This
|
||||
should be used when sending synchronisation messages to a legacy
|
||||
system that only understands the original synchronisation protocol.
|
||||
|
||||
1 selects the current synchronisation protocol (version 1). This
|
||||
should be used where possible.
|
||||
|
||||
Kernels with this sync_version entry are able to receive messages
|
||||
of both version 1 and version 2 of the synchronisation protocol.
|
||||
|
|
|
|||
|
|
@ -263,6 +263,8 @@ characters, each representing a particular tainted value.
|
|||
12: 'I' if the kernel is working around a severe bug in the platform
|
||||
firmware (BIOS or similar).
|
||||
|
||||
13: 'O' if an externally-built ("out-of-tree") module has been loaded.
|
||||
|
||||
The primary reason for the 'Tainted: ' string is to tell kernel
|
||||
debuggers if this is a clean kernel or if anything unusual has
|
||||
occurred. Tainting is permanent: even if an offending module is
|
||||
|
|
|
|||
|
|
@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
|
|||
either wakes them up, if they are kernel threads, or sends fake signals to them,
|
||||
if they are user space processes. A task that has TIF_FREEZE set, should react
|
||||
to it by calling the function called refrigerator() (defined in
|
||||
kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state
|
||||
kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
|
||||
to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
|
||||
Then, we say that the task is 'frozen' and therefore the set of functions
|
||||
handling this mechanism is referred to as 'the freezer' (these functions are
|
||||
defined in kernel/power/process.c and include/linux/freezer.h). User space
|
||||
processes are generally frozen before kernel threads.
|
||||
defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
|
||||
User space processes are generally frozen before kernel threads.
|
||||
|
||||
It is not recommended to call refrigerator() directly. Instead, it is
|
||||
recommended to use the try_to_freeze() function (defined in
|
||||
|
|
@ -95,7 +95,7 @@ after the memory for the image has been freed, we don't want tasks to allocate
|
|||
additional memory and we prevent them from doing that by freezing them earlier.
|
||||
[Of course, this also means that device drivers should not allocate substantial
|
||||
amounts of memory from their .suspend() callbacks before hibernation, but this
|
||||
is e separate issue.]
|
||||
is a separate issue.]
|
||||
|
||||
3. The third reason is to prevent user space processes and some kernel threads
|
||||
from interfering with the suspending and resuming of devices. A user space
|
||||
|
|
|
|||
|
|
@ -789,6 +789,16 @@ will behave normally, not taking the autosuspend delay into account.
|
|||
Similarly, if the power.use_autosuspend field isn't set then the autosuspend
|
||||
helper functions will behave just like the non-autosuspend counterparts.
|
||||
|
||||
Under some circumstances a driver or subsystem may want to prevent a device
|
||||
from autosuspending immediately, even though the usage counter is zero and the
|
||||
autosuspend delay time has expired. If the ->runtime_suspend() callback
|
||||
returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is
|
||||
in the future (as it normally would be if the callback invoked
|
||||
pm_runtime_mark_last_busy()), the PM core will automatically reschedule the
|
||||
autosuspend. The ->runtime_suspend() callback can't do this rescheduling
|
||||
itself because no suspend requests of any kind are accepted while the device is
|
||||
suspending (i.e., while the callback is running).
|
||||
|
||||
The implementation is well suited for asynchronous use in interrupt contexts.
|
||||
However such use inevitably involves races, because the PM core can't
|
||||
synchronize ->runtime_suspend() callbacks with the arrival of I/O requests.
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ and the default device ID in order to access the device on the active port.
|
|||
|
||||
After the host has completed enumeration of the entire network it releases
|
||||
devices by clearing device ID locks (calls rio_clear_locks()). For each endpoint
|
||||
in the system, it sets the Master Enable bit in the Port General Control CSR
|
||||
in the system, it sets the Discovered bit in the Port General Control CSR
|
||||
to indicate that enumeration is completed and agents are allowed to execute
|
||||
passive discovery of the network.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,49 @@
|
|||
RapidIO subsystem mport driver for IDT Tsi721 PCI Express-to-SRIO bridge.
|
||||
=========================================================================
|
||||
|
||||
I. Overview
|
||||
|
||||
This driver implements all currently defined RapidIO mport callback functions.
|
||||
It supports maintenance read and write operations, inbound and outbound RapidIO
|
||||
doorbells, inbound maintenance port-writes and RapidIO messaging.
|
||||
|
||||
To generate SRIO maintenance transactions this driver uses one of Tsi721 DMA
|
||||
channels. This mechanism provides access to larger range of hop counts and
|
||||
destination IDs without need for changes in outbound window translation.
|
||||
|
||||
RapidIO messaging support uses dedicated messaging channels for each mailbox.
|
||||
For inbound messages this driver uses destination ID matching to forward messages
|
||||
into the corresponding message queue. Messaging callbacks are implemented to be
|
||||
fully compatible with RIONET driver (Ethernet over RapidIO messaging services).
|
||||
|
||||
II. Known problems
|
||||
|
||||
None.
|
||||
|
||||
III. To do
|
||||
|
||||
Add DMA data transfers (non-messaging).
|
||||
Add inbound region (SRIO-to-PCIe) mapping.
|
||||
|
||||
IV. Version History
|
||||
|
||||
1.0.0 - Initial driver release.
|
||||
|
||||
V. License
|
||||
-----------------------------------------------
|
||||
|
||||
Copyright(c) 2011 Integrated Device Technology, Inc. All rights reserved.
|
||||
|
||||
This program is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the Free
|
||||
Software Foundation; either version 2 of the License, or (at your option)
|
||||
any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
||||
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
||||
more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License along with
|
||||
this program; if not, write to the Free Software Foundation, Inc.,
|
||||
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
|
@ -20,8 +20,6 @@ Version: 1.2.14
|
|||
Date: 11/01/2001
|
||||
Historical Author: Andrew Manison <amanison@america.net>
|
||||
Primary Author: Doug McNash
|
||||
Support: support@computone.com
|
||||
Fixes and Updates: Mike Warfield <mhw@wittsend.com>
|
||||
|
||||
This file assumes that you are using the Computone drivers which are
|
||||
integrated into the kernel sources. For updating the drivers or installing
|
||||
|
|
|
|||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -0,0 +1,195 @@
|
|||
Converting old watchdog drivers to the watchdog framework
|
||||
by Wolfram Sang <w.sang@pengutronix.de>
|
||||
=========================================================
|
||||
|
||||
Before the watchdog framework came into the kernel, every driver had to
|
||||
implement the API on its own. Now, as the framework factored out the common
|
||||
components, those drivers can be lightened making it a user of the framework.
|
||||
This document shall guide you for this task. The necessary steps are described
|
||||
as well as things to look out for.
|
||||
|
||||
|
||||
Remove the file_operations struct
|
||||
---------------------------------
|
||||
|
||||
Old drivers define their own file_operations for actions like open(), write(),
|
||||
etc... These are now handled by the framework and just call the driver when
|
||||
needed. So, in general, the 'file_operations' struct and assorted functions can
|
||||
go. Only very few driver-specific details have to be moved to other functions.
|
||||
Here is a overview of the functions and probably needed actions:
|
||||
|
||||
- open: Everything dealing with resource management (file-open checks, magic
|
||||
close preparations) can simply go. Device specific stuff needs to go to the
|
||||
driver specific start-function. Note that for some drivers, the start-function
|
||||
also serves as the ping-function. If that is the case and you need start/stop
|
||||
to be balanced (clocks!), you are better off refactoring a separate start-function.
|
||||
|
||||
- close: Same hints as for open apply.
|
||||
|
||||
- write: Can simply go, all defined behaviour is taken care of by the framework,
|
||||
i.e. ping on write and magic char ('V') handling.
|
||||
|
||||
- ioctl: While the driver is allowed to have extensions to the IOCTL interface,
|
||||
the most common ones are handled by the framework, supported by some assistance
|
||||
from the driver:
|
||||
|
||||
WDIOC_GETSUPPORT:
|
||||
Returns the mandatory watchdog_info struct from the driver
|
||||
|
||||
WDIOC_GETSTATUS:
|
||||
Needs the status-callback defined, otherwise returns 0
|
||||
|
||||
WDIOC_GETBOOTSTATUS:
|
||||
Needs the bootstatus member properly set. Make sure it is 0 if you
|
||||
don't have further support!
|
||||
|
||||
WDIOC_SETOPTIONS:
|
||||
No preparations needed
|
||||
|
||||
WDIOC_KEEPALIVE:
|
||||
If wanted, options in watchdog_info need to have WDIOF_KEEPALIVEPING
|
||||
set
|
||||
|
||||
WDIOC_SETTIMEOUT:
|
||||
Options in watchdog_info need to have WDIOF_SETTIMEOUT set
|
||||
and a set_timeout-callback has to be defined. The core will also
|
||||
do limit-checking, if min_timeout and max_timeout in the watchdog
|
||||
device are set. All is optional.
|
||||
|
||||
WDIOC_GETTIMEOUT:
|
||||
No preparations needed
|
||||
|
||||
Other IOCTLs can be served using the ioctl-callback. Note that this is mainly
|
||||
intended for porting old drivers; new drivers should not invent private IOCTLs.
|
||||
Private IOCTLs are processed first. When the callback returns with
|
||||
-ENOIOCTLCMD, the IOCTLs of the framework will be tried, too. Any other error
|
||||
is directly given to the user.
|
||||
|
||||
Example conversion:
|
||||
|
||||
-static const struct file_operations s3c2410wdt_fops = {
|
||||
- .owner = THIS_MODULE,
|
||||
- .llseek = no_llseek,
|
||||
- .write = s3c2410wdt_write,
|
||||
- .unlocked_ioctl = s3c2410wdt_ioctl,
|
||||
- .open = s3c2410wdt_open,
|
||||
- .release = s3c2410wdt_release,
|
||||
-};
|
||||
|
||||
Check the functions for device-specific stuff and keep it for later
|
||||
refactoring. The rest can go.
|
||||
|
||||
|
||||
Remove the miscdevice
|
||||
---------------------
|
||||
|
||||
Since the file_operations are gone now, you can also remove the 'struct
|
||||
miscdevice'. The framework will create it on watchdog_dev_register() called by
|
||||
watchdog_register_device().
|
||||
|
||||
-static struct miscdevice s3c2410wdt_miscdev = {
|
||||
- .minor = WATCHDOG_MINOR,
|
||||
- .name = "watchdog",
|
||||
- .fops = &s3c2410wdt_fops,
|
||||
-};
|
||||
|
||||
|
||||
Remove obsolete includes and defines
|
||||
------------------------------------
|
||||
|
||||
Because of the simplifications, a few defines are probably unused now. Remove
|
||||
them. Includes can be removed, too. For example:
|
||||
|
||||
- #include <linux/fs.h>
|
||||
- #include <linux/miscdevice.h> (if MODULE_ALIAS_MISCDEV is not used)
|
||||
- #include <linux/uaccess.h> (if no custom IOCTLs are used)
|
||||
|
||||
|
||||
Add the watchdog operations
|
||||
---------------------------
|
||||
|
||||
All possible callbacks are defined in 'struct watchdog_ops'. You can find it
|
||||
explained in 'watchdog-kernel-api.txt' in this directory. start(), stop() and
|
||||
owner must be set, the rest are optional. You will easily find corresponding
|
||||
functions in the old driver. Note that you will now get a pointer to the
|
||||
watchdog_device as a parameter to these functions, so you probably have to
|
||||
change the function header. Other changes are most likely not needed, because
|
||||
here simply happens the direct hardware access. If you have device-specific
|
||||
code left from the above steps, it should be refactored into these callbacks.
|
||||
|
||||
Here is a simple example:
|
||||
|
||||
+static struct watchdog_ops s3c2410wdt_ops = {
|
||||
+ .owner = THIS_MODULE,
|
||||
+ .start = s3c2410wdt_start,
|
||||
+ .stop = s3c2410wdt_stop,
|
||||
+ .ping = s3c2410wdt_keepalive,
|
||||
+ .set_timeout = s3c2410wdt_set_heartbeat,
|
||||
+};
|
||||
|
||||
A typical function-header change looks like:
|
||||
|
||||
-static void s3c2410wdt_keepalive(void)
|
||||
+static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
|
||||
{
|
||||
...
|
||||
+
|
||||
+ return 0;
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
- s3c2410wdt_keepalive();
|
||||
+ s3c2410wdt_keepalive(&s3c2410_wdd);
|
||||
|
||||
|
||||
Add the watchdog device
|
||||
-----------------------
|
||||
|
||||
Now we need to create a 'struct watchdog_device' and populate it with the
|
||||
necessary information for the framework. The struct is also explained in detail
|
||||
in 'watchdog-kernel-api.txt' in this directory. We pass it the mandatory
|
||||
watchdog_info struct and the newly created watchdog_ops. Often, old drivers
|
||||
have their own record-keeping for things like bootstatus and timeout using
|
||||
static variables. Those have to be converted to use the members in
|
||||
watchdog_device. Note that the timeout values are unsigned int. Some drivers
|
||||
use signed int, so this has to be converted, too.
|
||||
|
||||
Here is a simple example for a watchdog device:
|
||||
|
||||
+static struct watchdog_device s3c2410_wdd = {
|
||||
+ .info = &s3c2410_wdt_ident,
|
||||
+ .ops = &s3c2410wdt_ops,
|
||||
+};
|
||||
|
||||
|
||||
Register the watchdog device
|
||||
----------------------------
|
||||
|
||||
Replace misc_register(&miscdev) with watchdog_register_device(&watchdog_dev).
|
||||
Make sure the return value gets checked and the error message, if present,
|
||||
still fits. Also convert the unregister case.
|
||||
|
||||
- ret = misc_register(&s3c2410wdt_miscdev);
|
||||
+ ret = watchdog_register_device(&s3c2410_wdd);
|
||||
|
||||
...
|
||||
|
||||
- misc_deregister(&s3c2410wdt_miscdev);
|
||||
+ watchdog_unregister_device(&s3c2410_wdd);
|
||||
|
||||
|
||||
Update the Kconfig-entry
|
||||
------------------------
|
||||
|
||||
The entry for the driver now needs to select WATCHDOG_CORE:
|
||||
|
||||
+ select WATCHDOG_CORE
|
||||
|
||||
|
||||
Create a patch and send it to upstream
|
||||
--------------------------------------
|
||||
|
||||
Make sure you understood Documentation/SubmittingPatches and send your patch to
|
||||
linux-watchdog@vger.kernel.org. We are looking forward to it :)
|
||||
|
||||
6
Kbuild
6
Kbuild
|
|
@ -88,11 +88,13 @@ $(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s Kbuild
|
|||
# 3) Check for missing system calls
|
||||
#
|
||||
|
||||
always += missing-syscalls
|
||||
targets += missing-syscalls
|
||||
|
||||
quiet_cmd_syscalls = CALL $<
|
||||
cmd_syscalls = $(CONFIG_SHELL) $< $(CC) $(c_flags)
|
||||
|
||||
PHONY += missing-syscalls
|
||||
missing-syscalls: scripts/checksyscalls.sh FORCE
|
||||
missing-syscalls: scripts/checksyscalls.sh $(offsets-file) FORCE
|
||||
$(call cmd,syscalls)
|
||||
|
||||
# Keep these two files during make clean
|
||||
|
|
|
|||
34
MAINTAINERS
34
MAINTAINERS
|
|
@ -1716,6 +1716,7 @@ F: include/linux/can.h
|
|||
F: include/linux/can/core.h
|
||||
F: include/linux/can/bcm.h
|
||||
F: include/linux/can/raw.h
|
||||
F: include/linux/can/gw.h
|
||||
|
||||
CAN NETWORK DRIVERS
|
||||
M: Wolfgang Grandegger <wg@grandegger.com>
|
||||
|
|
@ -2386,7 +2387,7 @@ F: include/linux/netfilter_bridge/ebt_*.h
|
|||
F: net/bridge/netfilter/ebt*.c
|
||||
|
||||
ECRYPT FILE SYSTEM
|
||||
M: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
||||
M: Tyler Hicks <tyhicks@canonical.com>
|
||||
M: Dustin Kirkland <kirkland@canonical.com>
|
||||
L: ecryptfs@vger.kernel.org
|
||||
W: https://launchpad.net/ecryptfs
|
||||
|
|
@ -2467,8 +2468,6 @@ L: linux-edac@vger.kernel.org
|
|||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/i7core_edac.c
|
||||
F: drivers/edac/edac_mce.c
|
||||
F: include/linux/edac_mce.h
|
||||
|
||||
EDAC-I82975X
|
||||
M: Ranganathan Desikan <ravi@jetztechnologies.com>
|
||||
|
|
@ -2492,6 +2491,13 @@ W: bluesmoke.sourceforge.net
|
|||
S: Maintained
|
||||
F: drivers/edac/r82600_edac.c
|
||||
|
||||
EDAC-SBRIDGE
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/sb_edac.c
|
||||
|
||||
EDIROL UA-101/UA-1000 DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
|
|
@ -3013,6 +3019,13 @@ F: Documentation/hw_random.txt
|
|||
F: drivers/char/hw_random/
|
||||
F: include/linux/hw_random.h
|
||||
|
||||
HARDWARE SPINLOCK CORE
|
||||
M: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
S: Maintained
|
||||
F: Documentation/hwspinlock.txt
|
||||
F: drivers/hwspinlock/hwspinlock_*
|
||||
F: include/linux/hwspinlock.h
|
||||
|
||||
HARMONY SOUND DRIVER
|
||||
M: Kyle McMartin <kyle@mcmartin.ca>
|
||||
L: linux-parisc@vger.kernel.org
|
||||
|
|
@ -3205,8 +3218,7 @@ IA64 (Itanium) PLATFORM
|
|||
M: Tony Luck <tony.luck@intel.com>
|
||||
M: Fenghua Yu <fenghua.yu@intel.com>
|
||||
L: linux-ia64@vger.kernel.org
|
||||
W: http://www.ia64-linux.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git
|
||||
S: Maintained
|
||||
F: arch/ia64/
|
||||
|
||||
|
|
@ -4465,11 +4477,9 @@ F: Documentation/networking/vxge.txt
|
|||
F: drivers/net/ethernet/neterion/
|
||||
|
||||
NETFILTER/IPTABLES/IPCHAINS
|
||||
P: Rusty Russell
|
||||
P: Marc Boucher
|
||||
P: James Morris
|
||||
P: Harald Welte
|
||||
P: Jozsef Kadlecsik
|
||||
M: Pablo Neira Ayuso <pablo@netfilter.org>
|
||||
M: Patrick McHardy <kaber@trash.net>
|
||||
L: netfilter-devel@vger.kernel.org
|
||||
L: netfilter@vger.kernel.org
|
||||
|
|
@ -4710,6 +4720,13 @@ S: Maintained
|
|||
F: drivers/video/omap2/
|
||||
F: Documentation/arm/OMAP/DSS
|
||||
|
||||
OMAP HARDWARE SPINLOCK SUPPORT
|
||||
M: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/hwspinlock/omap_hwspinlock.c
|
||||
F: arch/arm/mach-omap2/hwspinlock.c
|
||||
|
||||
OMAP MMC SUPPORT
|
||||
M: Jarkko Lavinen <jarkko.lavinen@nokia.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
|
|
@ -6683,7 +6700,6 @@ F: drivers/net/ethernet/8390/ne-h8300.c
|
|||
|
||||
UDF FILESYSTEM
|
||||
M: Jan Kara <jack@suse.cz>
|
||||
W: http://linux-udf.sourceforge.net
|
||||
S: Maintained
|
||||
F: Documentation/filesystems/udf.txt
|
||||
F: fs/udf/
|
||||
|
|
|
|||
4
Makefile
4
Makefile
|
|
@ -983,7 +983,6 @@ archprepare: prepare1 scripts_basic
|
|||
|
||||
prepare0: archprepare FORCE
|
||||
$(Q)$(MAKE) $(build)=.
|
||||
$(Q)$(MAKE) $(build)=. missing-syscalls
|
||||
|
||||
# All the preparing..
|
||||
prepare: prepare0
|
||||
|
|
@ -1198,7 +1197,7 @@ distclean: mrproper
|
|||
@find $(srctree) $(RCS_FIND_IGNORE) \
|
||||
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
|
||||
-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
|
||||
-o -name '.*.rej' -o -size 0 \
|
||||
-o -name '.*.rej' \
|
||||
-o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
|
||||
-type f -print | xargs rm -f
|
||||
|
||||
|
|
@ -1296,7 +1295,6 @@ help:
|
|||
@echo ' 2: warnings which occur quite often but may still be relevant'
|
||||
@echo ' 3: more obscure warnings, can most likely be ignored'
|
||||
@echo ' Multiple levels can be combined with W=12 or W=123'
|
||||
@echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
|
||||
@echo ''
|
||||
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
|
||||
@echo 'For further info see the ./README file'
|
||||
|
|
|
|||
|
|
@ -445,11 +445,6 @@ config ALPHA_EV67
|
|||
Is this a machine based on the EV67 core? If in doubt, select N here
|
||||
and the machine will be treated as an EV6.
|
||||
|
||||
config ALPHA_EV7
|
||||
bool
|
||||
depends on ALPHA_MARVEL
|
||||
default y
|
||||
|
||||
config ALPHA_MCPCIA
|
||||
bool
|
||||
depends on ALPHA_RAWHIDE
|
||||
|
|
|
|||
|
|
@ -303,6 +303,7 @@ irongate_init_arch(void)
|
|||
#include <linux/vmalloc.h>
|
||||
#include <linux/agp_backend.h>
|
||||
#include <linux/agpgart.h>
|
||||
#include <linux/export.h>
|
||||
#include <asm/pgalloc.h>
|
||||
|
||||
#define GET_PAGE_DIR_OFF(addr) (addr >> 22)
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@
|
|||
*/
|
||||
|
||||
#include <linux/sched.h>
|
||||
#include <linux/stat.h>
|
||||
#include <linux/slab.h>
|
||||
#include <linux/pci.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@
|
|||
#include <linux/pci.h>
|
||||
#include <linux/gfp.h>
|
||||
#include <linux/bootmem.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/scatterlist.h>
|
||||
#include <linux/log2.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@
|
|||
#include <asm/setup.h>
|
||||
#include <asm/io.h>
|
||||
#include <linux/log2.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
extern struct atomic_notifier_head panic_notifier_list;
|
||||
static int alpha_panic_event(struct notifier_block *, unsigned long, void *);
|
||||
|
|
|
|||
|
|
@ -595,6 +595,7 @@ config ARCH_MMP
|
|||
select TICK_ONESHOT
|
||||
select PLAT_PXA
|
||||
select SPARSE_IRQ
|
||||
select GENERIC_ALLOCATOR
|
||||
help
|
||||
Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
|
||||
|
||||
|
|
@ -769,6 +770,7 @@ config ARCH_S3C64XX
|
|||
select CPU_V6
|
||||
select ARM_VIC
|
||||
select HAVE_CLK
|
||||
select HAVE_TCM
|
||||
select CLKDEV_LOOKUP
|
||||
select NO_IOPORT
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
|
|
@ -777,9 +779,6 @@ config ARCH_S3C64XX
|
|||
select SAMSUNG_CLKSRC
|
||||
select SAMSUNG_IRQ_VIC_TIMER
|
||||
select S3C_GPIO_TRACK
|
||||
select S3C_GPIO_PULL_UPDOWN
|
||||
select S3C_GPIO_CFG_S3C24XX
|
||||
select S3C_GPIO_CFG_S3C64XX
|
||||
select S3C_DEV_NAND
|
||||
select USB_ARCH_HAS_OHCI
|
||||
select SAMSUNG_GPIOLIB_4BIT
|
||||
|
|
@ -838,8 +837,8 @@ config ARCH_S5PV210
|
|||
help
|
||||
Samsung S5PV210/S5PC110 series based systems
|
||||
|
||||
config ARCH_EXYNOS4
|
||||
bool "Samsung EXYNOS4"
|
||||
config ARCH_EXYNOS
|
||||
bool "SAMSUNG EXYNOS"
|
||||
select CPU_V7
|
||||
select ARCH_SPARSEMEM_ENABLE
|
||||
select ARCH_HAS_HOLES_MEMORYMODEL
|
||||
|
|
@ -853,7 +852,7 @@ config ARCH_EXYNOS4
|
|||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
select NEED_MACH_MEMORY_H
|
||||
help
|
||||
Samsung EXYNOS4 series based systems
|
||||
Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
|
||||
|
||||
config ARCH_SHARK
|
||||
bool "Shark"
|
||||
|
|
@ -1080,7 +1079,7 @@ source "arch/arm/mach-s5pc100/Kconfig"
|
|||
|
||||
source "arch/arm/mach-s5pv210/Kconfig"
|
||||
|
||||
source "arch/arm/mach-exynos4/Kconfig"
|
||||
source "arch/arm/mach-exynos/Kconfig"
|
||||
|
||||
source "arch/arm/mach-shmobile/Kconfig"
|
||||
|
||||
|
|
@ -2212,7 +2211,7 @@ menu "Power management options"
|
|||
source "kernel/power/Kconfig"
|
||||
|
||||
config ARCH_SUSPEND_POSSIBLE
|
||||
depends on !ARCH_S5P64X0 && !ARCH_S5PC100
|
||||
depends on !ARCH_S5PC100
|
||||
depends on CPU_ARM920T || CPU_ARM926T || CPU_SA1100 || \
|
||||
CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE
|
||||
def_bool y
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ machine-$(CONFIG_ARCH_S3C64XX) := s3c64xx
|
|||
machine-$(CONFIG_ARCH_S5P64X0) := s5p64x0
|
||||
machine-$(CONFIG_ARCH_S5PC100) := s5pc100
|
||||
machine-$(CONFIG_ARCH_S5PV210) := s5pv210
|
||||
machine-$(CONFIG_ARCH_EXYNOS4) := exynos4
|
||||
machine-$(CONFIG_ARCH_EXYNOS4) := exynos
|
||||
machine-$(CONFIG_ARCH_SA1100) := sa1100
|
||||
machine-$(CONFIG_ARCH_SHARK) := shark
|
||||
machine-$(CONFIG_ARCH_SHMOBILE) := shmobile
|
||||
|
|
|
|||
|
|
@ -25,6 +25,7 @@
|
|||
#include <linux/ioport.h>
|
||||
#include <linux/irq.h>
|
||||
#include <linux/io.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <asm/mach/pci.h>
|
||||
#include <asm/hardware/it8152.h>
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@
|
|||
#include <linux/string.h>
|
||||
#include <linux/slab.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/io.h>
|
||||
#include <asm/hardware/scoop.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -4,19 +4,18 @@ CONFIG_KALLSYMS_ALL=y
|
|||
CONFIG_MODULES=y
|
||||
CONFIG_MODULE_UNLOAD=y
|
||||
# CONFIG_BLK_DEV_BSG is not set
|
||||
CONFIG_ARCH_EXYNOS4=y
|
||||
CONFIG_ARCH_EXYNOS=y
|
||||
CONFIG_S3C_LOWLEVEL_UART_PORT=1
|
||||
CONFIG_MACH_SMDKC210=y
|
||||
CONFIG_MACH_SMDKV310=y
|
||||
CONFIG_MACH_ARMLEX4210=y
|
||||
CONFIG_MACH_UNIVERSAL_C210=y
|
||||
CONFIG_MACH_NURI=y
|
||||
CONFIG_MACH_ORIGEN=y
|
||||
CONFIG_MACH_SMDK4412=y
|
||||
CONFIG_NO_HZ=y
|
||||
CONFIG_HIGH_RES_TIMERS=y
|
||||
CONFIG_SMP=y
|
||||
CONFIG_NR_CPUS=2
|
||||
CONFIG_HOTPLUG_CPU=y
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_AEABI=y
|
||||
CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
|
||||
|
|
@ -61,13 +60,9 @@ CONFIG_DETECT_HUNG_TASK=y
|
|||
CONFIG_DEBUG_RT_MUTEXES=y
|
||||
CONFIG_DEBUG_SPINLOCK=y
|
||||
CONFIG_DEBUG_MUTEXES=y
|
||||
CONFIG_DEBUG_SPINLOCK_SLEEP=y
|
||||
CONFIG_DEBUG_INFO=y
|
||||
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
|
||||
CONFIG_SYSCTL_SYSCALL_CHECK=y
|
||||
CONFIG_DEBUG_USER=y
|
||||
CONFIG_DEBUG_ERRORS=y
|
||||
CONFIG_DEBUG_LL=y
|
||||
CONFIG_EARLY_PRINTK=y
|
||||
CONFIG_DEBUG_S3C_UART=1
|
||||
CONFIG_CRC_CCITT=y
|
||||
|
|
|
|||
|
|
@ -21,6 +21,9 @@
|
|||
* OneNAND features.
|
||||
*/
|
||||
|
||||
#ifndef ASM_PL080_H
|
||||
#define ASM_PL080_H
|
||||
|
||||
#define PL080_INT_STATUS (0x00)
|
||||
#define PL080_TC_STATUS (0x04)
|
||||
#define PL080_TC_CLEAR (0x08)
|
||||
|
|
@ -138,3 +141,4 @@ struct pl080s_lli {
|
|||
u32 control1;
|
||||
};
|
||||
|
||||
#endif /* ASM_PL080_H */
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/string.h>
|
||||
#include <linux/cryptohash.h>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
*
|
||||
* Bits taken from various places.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/pci.h>
|
||||
#include <linux/slab.h>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/errno.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/bootmem.h>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/personality.h>
|
||||
#include <linux/binfmts.h>
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@
|
|||
#include <linux/miscdevice.h>
|
||||
#include <linux/vmalloc.h>
|
||||
#include <linux/mutex.h>
|
||||
#include <linux/module.h>
|
||||
#include <asm/hardware/coresight.h>
|
||||
#include <asm/sections.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/io.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@
|
|||
* Naturally it's not a 1:1 relation, but there are similarities.
|
||||
*/
|
||||
#include <linux/kernel_stat.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/signal.h>
|
||||
#include <linux/ioport.h>
|
||||
#include <linux/interrupt.h>
|
||||
|
|
|
|||
|
|
@ -7,10 +7,11 @@
|
|||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/sysdev.h>
|
||||
#include <linux/syscore_ops.h>
|
||||
#include <linux/string.h>
|
||||
|
||||
#include <asm/leds.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
#include <linux/bitmap.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/perf_event.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/spinlock.h>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
* published by the Free Software Foundation.
|
||||
*/
|
||||
|
||||
#include <linux/module.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/signal.h>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
*/
|
||||
#include <stdarg.h>
|
||||
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/mm.h>
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@
|
|||
#include <linux/kernel.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/mm.h>
|
||||
#include <linux/elf.h>
|
||||
#include <linux/smp.h>
|
||||
#include <linux/ptrace.h>
|
||||
#include <linux/user.h>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
* under the terms of the GNU General Public License version 2 as published by
|
||||
* the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/ftrace.h>
|
||||
|
||||
#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/stddef.h>
|
||||
#include <linux/ioport.h>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/stacktrace.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
* have a non-standard calling sequence on the Linux/arm
|
||||
* platform.
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/errno.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/mm.h>
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
* This file contains the ARM-specific time handling details:
|
||||
* reading the RTC at bootup, etc...
|
||||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/time.h>
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@
|
|||
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/export.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/slab.h>
|
||||
#include <linux/spinlock.h>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@
|
|||
* published by the Free Software Foundation.
|
||||
*/
|
||||
|
||||
#include <linux/module.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/signal.h>
|
||||
|
|
|
|||
|
|
@ -195,12 +195,6 @@ if ARCH_AT91SAM9260
|
|||
|
||||
comment "AT91SAM9260 Variants"
|
||||
|
||||
config ARCH_AT91SAM9260_SAM9XE
|
||||
bool "AT91SAM9XE"
|
||||
help
|
||||
Select this if you are using Atmel's AT91SAM9XE System-on-Chip.
|
||||
They are basically AT91SAM9260s with various sizes of embedded Flash.
|
||||
|
||||
comment "AT91SAM9260 / AT91SAM9XE Board Type"
|
||||
|
||||
config MACH_AT91SAM9260EK
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@
|
|||
#include <linux/cpuidle.h>
|
||||
#include <asm/proc-fns.h>
|
||||
#include <linux/io.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include "pm.h"
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@
|
|||
#include <linux/device.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/irqreturn.h>
|
||||
#include <linux/proc_fs.h>
|
||||
#include <linux/slab.h>
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <asm/page.h>
|
||||
#include <asm/mach/map.h>
|
||||
|
||||
#include <mach/hardware.h>
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@
|
|||
#include <linux/phy.h>
|
||||
#include <linux/clk.h>
|
||||
#include <linux/videodev2.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <media/tvp514x.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@
|
|||
#include <linux/mtd/nand.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
#include <linux/clk.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <asm/mach-types.h>
|
||||
#include <asm/mach/arch.h>
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@
|
|||
#include <linux/clk.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/i2c.h>
|
||||
#include <linux/module.h>
|
||||
|
||||
#include <mach/clock.h>
|
||||
#include <mach/cdce949.h>
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@
|
|||
#include <linux/err.h>
|
||||
#include <linux/clk.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <mach/hardware.h>
|
||||
#include <mach/cpufreq.h>
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@
|
|||
#include <linux/platform_device.h>
|
||||
#include <linux/cpuidle.h>
|
||||
#include <linux/io.h>
|
||||
#include <linux/export.h>
|
||||
#include <asm/proc-fns.h>
|
||||
|
||||
#include <mach/cpuidle.h>
|
||||
|
|
|
|||
|
|
@ -15,6 +15,8 @@
|
|||
|
||||
#include <asm-generic/gpio.h>
|
||||
|
||||
#define __ARM_GPIOLIB_COMPLEX
|
||||
|
||||
/* The inline versions use the static inlines in the driver header */
|
||||
#include "gpio-davinci.h"
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@
|
|||
#include <linux/i2c.h>
|
||||
#include <linux/i2c-gpio.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <mach/hardware.h>
|
||||
#include <mach/fb.h>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# arch/arm/mach-exynos4/Kconfig
|
||||
# arch/arm/mach-exynos/Kconfig
|
||||
#
|
||||
# Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
|
||||
# http://www.samsung.com/
|
||||
|
|
@ -7,22 +7,47 @@
|
|||
|
||||
# Configuration options for the EXYNOS4
|
||||
|
||||
if ARCH_EXYNOS4
|
||||
if ARCH_EXYNOS
|
||||
|
||||
menu "SAMSUNG EXYNOS SoCs Support"
|
||||
|
||||
choice
|
||||
prompt "EXYNOS System Type"
|
||||
default ARCH_EXYNOS4
|
||||
|
||||
config ARCH_EXYNOS4
|
||||
bool "SAMSUNG EXYNOS4"
|
||||
help
|
||||
Samsung EXYNOS4 SoCs based systems
|
||||
|
||||
endchoice
|
||||
|
||||
comment "EXYNOS SoCs"
|
||||
|
||||
config CPU_EXYNOS4210
|
||||
bool
|
||||
select S3C_PL330_DMA
|
||||
bool "SAMSUNG EXYNOS4210"
|
||||
default y
|
||||
depends on ARCH_EXYNOS4
|
||||
select SAMSUNG_DMADEV
|
||||
select ARM_CPU_SUSPEND if PM
|
||||
select S5P_PM if PM
|
||||
select S5P_SLEEP if PM
|
||||
help
|
||||
Enable EXYNOS4210 CPU support
|
||||
|
||||
config SOC_EXYNOS4212
|
||||
bool
|
||||
bool "SAMSUNG EXYNOS4212"
|
||||
default y
|
||||
depends on ARCH_EXYNOS4
|
||||
select S5P_PM if PM
|
||||
select S5P_SLEEP if PM
|
||||
help
|
||||
Enable EXYNOS4212 SoC support
|
||||
|
||||
config SOC_EXYNOS4412
|
||||
bool
|
||||
bool "SAMSUNG EXYNOS4412"
|
||||
default y
|
||||
depends on ARCH_EXYNOS4
|
||||
help
|
||||
Enable EXYNOS4412 SoC support
|
||||
|
||||
|
|
@ -120,7 +145,7 @@ config EXYNOS4_SETUP_USB_PHY
|
|||
|
||||
# machine support
|
||||
|
||||
menu "EXYNOS4 Machines"
|
||||
if ARCH_EXYNOS4
|
||||
|
||||
comment "EXYNOS4210 Boards"
|
||||
|
||||
|
|
@ -137,6 +162,14 @@ config MACH_SMDKV310
|
|||
select S3C_DEV_RTC
|
||||
select S3C_DEV_WDT
|
||||
select S3C_DEV_I2C1
|
||||
select S5P_DEV_FIMC0
|
||||
select S5P_DEV_FIMC1
|
||||
select S5P_DEV_FIMC2
|
||||
select S5P_DEV_FIMC3
|
||||
select S5P_DEV_I2C_HDMIPHY
|
||||
select S5P_DEV_MFC
|
||||
select S5P_DEV_TV
|
||||
select S5P_DEV_USB_EHCI
|
||||
select S3C_DEV_HSMMC
|
||||
select S3C_DEV_HSMMC1
|
||||
select S3C_DEV_HSMMC2
|
||||
|
|
@ -151,6 +184,7 @@ config MACH_SMDKV310
|
|||
select EXYNOS4_SETUP_I2C1
|
||||
select EXYNOS4_SETUP_KEYPAD
|
||||
select EXYNOS4_SETUP_SDHCI
|
||||
select EXYNOS4_SETUP_USB_PHY
|
||||
help
|
||||
Machine support for Samsung SMDKV310
|
||||
|
||||
|
|
@ -176,19 +210,26 @@ config MACH_UNIVERSAL_C210
|
|||
select S5P_DEV_FIMC1
|
||||
select S5P_DEV_FIMC2
|
||||
select S5P_DEV_FIMC3
|
||||
select S5P_DEV_CSIS0
|
||||
select S5P_DEV_FIMD0
|
||||
select S3C_DEV_HSMMC
|
||||
select S3C_DEV_HSMMC2
|
||||
select S3C_DEV_HSMMC3
|
||||
select S3C_DEV_I2C1
|
||||
select S3C_DEV_I2C3
|
||||
select S3C_DEV_I2C5
|
||||
select S5P_DEV_I2C_HDMIPHY
|
||||
select S5P_DEV_MFC
|
||||
select S5P_DEV_ONENAND
|
||||
select S5P_DEV_TV
|
||||
select EXYNOS4_DEV_PD
|
||||
select EXYNOS4_SETUP_FIMD0
|
||||
select EXYNOS4_SETUP_I2C1
|
||||
select EXYNOS4_SETUP_I2C3
|
||||
select EXYNOS4_SETUP_I2C5
|
||||
select EXYNOS4_SETUP_SDHCI
|
||||
select EXYNOS4_SETUP_FIMC
|
||||
select S5P_SETUP_MIPIPHY
|
||||
help
|
||||
Machine support for Samsung Mobile Universal S5PC210 Reference
|
||||
Board.
|
||||
|
|
@ -196,21 +237,33 @@ config MACH_UNIVERSAL_C210
|
|||
config MACH_NURI
|
||||
bool "Mobile NURI Board"
|
||||
select CPU_EXYNOS4210
|
||||
select S5P_GPIO_INT
|
||||
select S3C_DEV_WDT
|
||||
select S3C_DEV_RTC
|
||||
select S5P_DEV_FIMD0
|
||||
select S3C_DEV_HSMMC
|
||||
select S3C_DEV_HSMMC2
|
||||
select S3C_DEV_HSMMC3
|
||||
select S3C_DEV_I2C1
|
||||
select S3C_DEV_I2C3
|
||||
select S3C_DEV_I2C5
|
||||
select S5P_DEV_CSIS0
|
||||
select S5P_DEV_FIMC0
|
||||
select S5P_DEV_FIMC1
|
||||
select S5P_DEV_FIMC2
|
||||
select S5P_DEV_FIMC3
|
||||
select S5P_DEV_MFC
|
||||
select S5P_DEV_USB_EHCI
|
||||
select S5P_SETUP_MIPIPHY
|
||||
select EXYNOS4_DEV_PD
|
||||
select EXYNOS4_SETUP_FIMC
|
||||
select EXYNOS4_SETUP_FIMD0
|
||||
select EXYNOS4_SETUP_I2C1
|
||||
select EXYNOS4_SETUP_I2C3
|
||||
select EXYNOS4_SETUP_I2C5
|
||||
select EXYNOS4_SETUP_SDHCI
|
||||
select EXYNOS4_SETUP_USB_PHY
|
||||
select S5P_SETUP_MIPIPHY
|
||||
select SAMSUNG_DEV_PWM
|
||||
select SAMSUNG_DEV_ADC
|
||||
help
|
||||
|
|
@ -221,8 +274,23 @@ config MACH_ORIGEN
|
|||
select CPU_EXYNOS4210
|
||||
select S3C_DEV_RTC
|
||||
select S3C_DEV_WDT
|
||||
select S3C_DEV_HSMMC
|
||||
select S3C_DEV_HSMMC2
|
||||
select S5P_DEV_FIMC0
|
||||
select S5P_DEV_FIMC1
|
||||
select S5P_DEV_FIMC2
|
||||
select S5P_DEV_FIMC3
|
||||
select S5P_DEV_FIMD0
|
||||
select S5P_DEV_I2C_HDMIPHY
|
||||
select S5P_DEV_MFC
|
||||
select S5P_DEV_TV
|
||||
select S5P_DEV_USB_EHCI
|
||||
select SAMSUNG_DEV_BACKLIGHT
|
||||
select SAMSUNG_DEV_PWM
|
||||
select EXYNOS4_DEV_PD
|
||||
select EXYNOS4_SETUP_FIMD0
|
||||
select EXYNOS4_SETUP_SDHCI
|
||||
select EXYNOS4_SETUP_USB_PHY
|
||||
help
|
||||
Machine support for ORIGEN based on Samsung EXYNOS4210
|
||||
|
||||
|
|
@ -257,12 +325,11 @@ config MACH_SMDK4412
|
|||
select MACH_SMDK4212
|
||||
help
|
||||
Machine support for Samsung SMDK4412
|
||||
endif
|
||||
|
||||
endmenu
|
||||
if ARCH_EXYNOS4
|
||||
|
||||
comment "Configuration for HSMMC bus width"
|
||||
|
||||
menu "Use 8-bit bus width"
|
||||
comment "Configuration for HSMMC 8-bit bus width"
|
||||
|
||||
config EXYNOS4_SDHCI_CH0_8BIT
|
||||
bool "Channel 0 with 8-bit bus"
|
||||
|
|
@ -275,6 +342,7 @@ config EXYNOS4_SDHCI_CH2_8BIT
|
|||
help
|
||||
Support HSMMC Channel 2 8-bit bus.
|
||||
If selected, Channel 3 is disabled.
|
||||
endif
|
||||
|
||||
endmenu
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# arch/arm/mach-exynos4/Makefile
|
||||
# arch/arm/mach-exynos/Makefile
|
||||
#
|
||||
# Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
|
||||
# http://www.samsung.com/
|
||||
|
|
@ -12,11 +12,11 @@ obj- :=
|
|||
|
||||
# Core support for EXYNOS4 system
|
||||
|
||||
obj-$(CONFIG_ARCH_EXYNOS4) += cpu.o init.o clock.o irq-combiner.o
|
||||
obj-$(CONFIG_ARCH_EXYNOS4) += setup-i2c0.o irq-eint.o dma.o pmu.o
|
||||
obj-$(CONFIG_ARCH_EXYNOS4) += cpu.o init.o clock.o irq-combiner.o setup-i2c0.o
|
||||
obj-$(CONFIG_ARCH_EXYNOS4) += irq-eint.o dma.o pmu.o
|
||||
obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
|
||||
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
|
||||
obj-$(CONFIG_PM) += pm.o sleep.o
|
||||
obj-$(CONFIG_PM) += pm.o
|
||||
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
|
||||
|
||||
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
|
||||
|
|
@ -39,11 +39,11 @@ obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
|
|||
|
||||
# device support
|
||||
|
||||
obj-y += dev-audio.o
|
||||
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
|
||||
obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
|
||||
obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
|
||||
obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
|
||||
obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
|
||||
obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
|
||||
|
||||
obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
|
||||
obj-$(CONFIG_EXYNOS4_SETUP_FIMD0) += setup-fimd0.o
|
||||
|
|
@ -57,5 +57,4 @@ obj-$(CONFIG_EXYNOS4_SETUP_I2C7) += setup-i2c7.o
|
|||
obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD) += setup-keypad.o
|
||||
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI) += setup-sdhci.o
|
||||
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
|
||||
|
||||
obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY) += setup-usb-phy.o
|
||||
|
|
@ -111,6 +111,11 @@ struct clk clk_sclk_usbphy1 = {
|
|||
.name = "sclk_usbphy1",
|
||||
};
|
||||
|
||||
static struct clk dummy_apb_pclk = {
|
||||
.name = "apb_pclk",
|
||||
.id = -1,
|
||||
};
|
||||
|
||||
static int exynos4_clksrc_mask_top_ctrl(struct clk *clk, int enable)
|
||||
{
|
||||
return s5p_gatectrl(S5P_CLKSRC_MASK_TOP, clk, enable);
|
||||
|
|
@ -146,6 +151,11 @@ static int exynos4_clk_ip_mfc_ctrl(struct clk *clk, int enable)
|
|||
return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
|
||||
}
|
||||
|
||||
static int exynos4_clksrc_mask_tv_ctrl(struct clk *clk, int enable)
|
||||
{
|
||||
return s5p_gatectrl(S5P_CLKSRC_MASK_TV, clk, enable);
|
||||
}
|
||||
|
||||
static int exynos4_clk_ip_cam_ctrl(struct clk *clk, int enable)
|
||||
{
|
||||
return s5p_gatectrl(S5P_CLKGATE_IP_CAM, clk, enable);
|
||||
|
|
@ -186,6 +196,16 @@ static int exynos4_clk_ip_perir_ctrl(struct clk *clk, int enable)
|
|||
return s5p_gatectrl(S5P_CLKGATE_IP_PERIR, clk, enable);
|
||||
}
|
||||
|
||||
static int exynos4_clk_hdmiphy_ctrl(struct clk *clk, int enable)
|
||||
{
|
||||
return s5p_gatectrl(S5P_HDMI_PHY_CONTROL, clk, enable);
|
||||
}
|
||||
|
||||
static int exynos4_clk_dac_ctrl(struct clk *clk, int enable)
|
||||
{
|
||||
return s5p_gatectrl(S5P_DAC_PHY_CONTROL, clk, enable);
|
||||
}
|
||||
|
||||
/* Core list of CMU_CPU side */
|
||||
|
||||
static struct clksrc_clk clk_mout_apll = {
|
||||
|
|
@ -503,13 +523,43 @@ static struct clk init_clocks_off[] = {
|
|||
.enable = exynos4_clk_ip_fsys_ctrl,
|
||||
.ctrlbit = (1 << 9),
|
||||
}, {
|
||||
.name = "pdma",
|
||||
.devname = "s3c-pl330.0",
|
||||
.name = "dac",
|
||||
.devname = "s5p-sdo",
|
||||
.enable = exynos4_clk_ip_tv_ctrl,
|
||||
.ctrlbit = (1 << 2),
|
||||
}, {
|
||||
.name = "mixer",
|
||||
.devname = "s5p-mixer",
|
||||
.enable = exynos4_clk_ip_tv_ctrl,
|
||||
.ctrlbit = (1 << 1),
|
||||
}, {
|
||||
.name = "vp",
|
||||
.devname = "s5p-mixer",
|
||||
.enable = exynos4_clk_ip_tv_ctrl,
|
||||
.ctrlbit = (1 << 0),
|
||||
}, {
|
||||
.name = "hdmi",
|
||||
.devname = "exynos4-hdmi",
|
||||
.enable = exynos4_clk_ip_tv_ctrl,
|
||||
.ctrlbit = (1 << 3),
|
||||
}, {
|
||||
.name = "hdmiphy",
|
||||
.devname = "exynos4-hdmi",
|
||||
.enable = exynos4_clk_hdmiphy_ctrl,
|
||||
.ctrlbit = (1 << 0),
|
||||
}, {
|
||||
.name = "dacphy",
|
||||
.devname = "s5p-sdo",
|
||||
.enable = exynos4_clk_dac_ctrl,
|
||||
.ctrlbit = (1 << 0),
|
||||
}, {
|
||||
.name = "dma",
|
||||
.devname = "dma-pl330.0",
|
||||
.enable = exynos4_clk_ip_fsys_ctrl,
|
||||
.ctrlbit = (1 << 0),
|
||||
}, {
|
||||
.name = "pdma",
|
||||
.devname = "s3c-pl330.1",
|
||||
.name = "dma",
|
||||
.devname = "dma-pl330.1",
|
||||
.enable = exynos4_clk_ip_fsys_ctrl,
|
||||
.ctrlbit = (1 << 1),
|
||||
}, {
|
||||
|
|
@ -629,6 +679,12 @@ static struct clk init_clocks_off[] = {
|
|||
.parent = &clk_aclk_100.clk,
|
||||
.enable = exynos4_clk_ip_peril_ctrl,
|
||||
.ctrlbit = (1 << 13),
|
||||
}, {
|
||||
.name = "i2c",
|
||||
.devname = "s3c2440-hdmiphy-i2c",
|
||||
.parent = &clk_aclk_100.clk,
|
||||
.enable = exynos4_clk_ip_peril_ctrl,
|
||||
.ctrlbit = (1 << 14),
|
||||
}, {
|
||||
.name = "SYSMMU_MDMA",
|
||||
.enable = exynos4_clk_ip_image_ctrl,
|
||||
|
|
@ -831,6 +887,81 @@ static struct clksrc_sources clkset_mout_mfc = {
|
|||
.nr_sources = ARRAY_SIZE(clkset_mout_mfc_list),
|
||||
};
|
||||
|
||||
static struct clk *clkset_sclk_dac_list[] = {
|
||||
[0] = &clk_sclk_vpll.clk,
|
||||
[1] = &clk_sclk_hdmiphy,
|
||||
};
|
||||
|
||||
static struct clksrc_sources clkset_sclk_dac = {
|
||||
.sources = clkset_sclk_dac_list,
|
||||
.nr_sources = ARRAY_SIZE(clkset_sclk_dac_list),
|
||||
};
|
||||
|
||||
static struct clksrc_clk clk_sclk_dac = {
|
||||
.clk = {
|
||||
.name = "sclk_dac",
|
||||
.enable = exynos4_clksrc_mask_tv_ctrl,
|
||||
.ctrlbit = (1 << 8),
|
||||
},
|
||||
.sources = &clkset_sclk_dac,
|
||||
.reg_src = { .reg = S5P_CLKSRC_TV, .shift = 8, .size = 1 },
|
||||
};
|
||||
|
||||
static struct clksrc_clk clk_sclk_pixel = {
|
||||
.clk = {
|
||||
.name = "sclk_pixel",
|
||||
.parent = &clk_sclk_vpll.clk,
|
||||
},
|
||||
.reg_div = { .reg = S5P_CLKDIV_TV, .shift = 0, .size = 4 },
|
||||
};
|
||||
|
||||
static struct clk *clkset_sclk_hdmi_list[] = {
|
||||
[0] = &clk_sclk_pixel.clk,
|
||||
[1] = &clk_sclk_hdmiphy,
|
||||
};
|
||||
|
||||
static struct clksrc_sources clkset_sclk_hdmi = {
|
||||
.sources = clkset_sclk_hdmi_list,
|
||||
.nr_sources = ARRAY_SIZE(clkset_sclk_hdmi_list),
|
||||
};
|
||||
|
||||
static struct clksrc_clk clk_sclk_hdmi = {
|
||||
.clk = {
|
||||
.name = "sclk_hdmi",
|
||||
.enable = exynos4_clksrc_mask_tv_ctrl,
|
||||
.ctrlbit = (1 << 0),
|
||||
},
|
||||
.sources = &clkset_sclk_hdmi,
|
||||
.reg_src = { .reg = S5P_CLKSRC_TV, .shift = 0, .size = 1 },
|
||||
};
|
||||
|
||||
static struct clk *clkset_sclk_mixer_list[] = {
|
||||
[0] = &clk_sclk_dac.clk,
|
||||
[1] = &clk_sclk_hdmi.clk,
|
||||
};
|
||||
|
||||
static struct clksrc_sources clkset_sclk_mixer = {
|
||||
.sources = clkset_sclk_mixer_list,
|
||||
.nr_sources = ARRAY_SIZE(clkset_sclk_mixer_list),
|
||||
};
|
||||
|
||||
static struct clksrc_clk clk_sclk_mixer = {
|
||||
.clk = {
|
||||
.name = "sclk_mixer",
|
||||
.enable = exynos4_clksrc_mask_tv_ctrl,
|
||||
.ctrlbit = (1 << 4),
|
||||
},
|
||||
.sources = &clkset_sclk_mixer,
|
||||
.reg_src = { .reg = S5P_CLKSRC_TV, .shift = 4, .size = 1 },
|
||||
};
|
||||
|
||||
static struct clksrc_clk *sclk_tv[] = {
|
||||
&clk_sclk_dac,
|
||||
&clk_sclk_pixel,
|
||||
&clk_sclk_hdmi,
|
||||
&clk_sclk_mixer,
|
||||
};
|
||||
|
||||
static struct clksrc_clk clk_dout_mmc0 = {
|
||||
.clk = {
|
||||
.name = "dout_mmc0",
|
||||
|
|
@ -1157,6 +1288,71 @@ static struct clk_ops exynos4_fout_apll_ops = {
|
|||
.get_rate = exynos4_fout_apll_get_rate,
|
||||
};
|
||||
|
||||
static u32 vpll_div[][8] = {
|
||||
{ 54000000, 3, 53, 3, 1024, 0, 17, 0 },
|
||||
{ 108000000, 3, 53, 2, 1024, 0, 17, 0 },
|
||||
};
|
||||
|
||||
static unsigned long exynos4_vpll_get_rate(struct clk *clk)
|
||||
{
|
||||
return clk->rate;
|
||||
}
|
||||
|
||||
static int exynos4_vpll_set_rate(struct clk *clk, unsigned long rate)
|
||||
{
|
||||
unsigned int vpll_con0, vpll_con1 = 0;
|
||||
unsigned int i;
|
||||
|
||||
/* Return if nothing changed */
|
||||
if (clk->rate == rate)
|
||||
return 0;
|
||||
|
||||
vpll_con0 = __raw_readl(S5P_VPLL_CON0);
|
||||
vpll_con0 &= ~(0x1 << 27 | \
|
||||
PLL90XX_MDIV_MASK << PLL46XX_MDIV_SHIFT | \
|
||||
PLL90XX_PDIV_MASK << PLL46XX_PDIV_SHIFT | \
|
||||
PLL90XX_SDIV_MASK << PLL46XX_SDIV_SHIFT);
|
||||
|
||||
vpll_con1 = __raw_readl(S5P_VPLL_CON1);
|
||||
vpll_con1 &= ~(PLL46XX_MRR_MASK << PLL46XX_MRR_SHIFT | \
|
||||
PLL46XX_MFR_MASK << PLL46XX_MFR_SHIFT | \
|
||||
PLL4650C_KDIV_MASK << PLL46XX_KDIV_SHIFT);
|
||||
|
||||
for (i = 0; i < ARRAY_SIZE(vpll_div); i++) {
|
||||
if (vpll_div[i][0] == rate) {
|
||||
vpll_con0 |= vpll_div[i][1] << PLL46XX_PDIV_SHIFT;
|
||||
vpll_con0 |= vpll_div[i][2] << PLL46XX_MDIV_SHIFT;
|
||||
vpll_con0 |= vpll_div[i][3] << PLL46XX_SDIV_SHIFT;
|
||||
vpll_con1 |= vpll_div[i][4] << PLL46XX_KDIV_SHIFT;
|
||||
vpll_con1 |= vpll_div[i][5] << PLL46XX_MFR_SHIFT;
|
||||
vpll_con1 |= vpll_div[i][6] << PLL46XX_MRR_SHIFT;
|
||||
vpll_con0 |= vpll_div[i][7] << 27;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
if (i == ARRAY_SIZE(vpll_div)) {
|
||||
printk(KERN_ERR "%s: Invalid Clock VPLL Frequency\n",
|
||||
__func__);
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
__raw_writel(vpll_con0, S5P_VPLL_CON0);
|
||||
__raw_writel(vpll_con1, S5P_VPLL_CON1);
|
||||
|
||||
/* Wait for VPLL lock */
|
||||
while (!(__raw_readl(S5P_VPLL_CON0) & (1 << PLL46XX_LOCKED_SHIFT)))
|
||||
continue;
|
||||
|
||||
clk->rate = rate;
|
||||
return 0;
|
||||
}
|
||||
|
||||
static struct clk_ops exynos4_vpll_ops = {
|
||||
.get_rate = exynos4_vpll_get_rate,
|
||||
.set_rate = exynos4_vpll_set_rate,
|
||||
};
|
||||
|
||||
void __init_or_cpufreq exynos4_setup_clocks(void)
|
||||
{
|
||||
struct clk *xtal_clk;
|
||||
|
|
@ -1214,6 +1410,7 @@ void __init_or_cpufreq exynos4_setup_clocks(void)
|
|||
clk_fout_apll.ops = &exynos4_fout_apll_ops;
|
||||
clk_fout_mpll.rate = mpll;
|
||||
clk_fout_epll.rate = epll;
|
||||
clk_fout_vpll.ops = &exynos4_vpll_ops;
|
||||
clk_fout_vpll.rate = vpll;
|
||||
|
||||
printk(KERN_INFO "EXYNOS4: PLL settings, A=%ld, M=%ld, E=%ld V=%ld",
|
||||
|
|
@ -1241,7 +1438,10 @@ void __init_or_cpufreq exynos4_setup_clocks(void)
|
|||
}
|
||||
|
||||
static struct clk *clks[] __initdata = {
|
||||
/* Nothing here yet */
|
||||
&clk_sclk_hdmi27m,
|
||||
&clk_sclk_hdmiphy,
|
||||
&clk_sclk_usbphy0,
|
||||
&clk_sclk_usbphy1,
|
||||
};
|
||||
|
||||
#ifdef CONFIG_PM_SLEEP
|
||||
|
|
@ -1275,6 +1475,9 @@ void __init exynos4_register_clocks(void)
|
|||
for (ptr = 0; ptr < ARRAY_SIZE(sysclks); ptr++)
|
||||
s3c_register_clksrc(sysclks[ptr], 1);
|
||||
|
||||
for (ptr = 0; ptr < ARRAY_SIZE(sclk_tv); ptr++)
|
||||
s3c_register_clksrc(sclk_tv[ptr], 1);
|
||||
|
||||
s3c_register_clksrc(clksrcs, ARRAY_SIZE(clksrcs));
|
||||
s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
|
||||
|
||||
|
|
@ -1282,5 +1485,7 @@ void __init exynos4_register_clocks(void)
|
|||
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
|
||||
|
||||
register_syscore_ops(&exynos4_clock_syscore_ops);
|
||||
s3c24xx_register_clock(&dummy_apb_pclk);
|
||||
|
||||
s3c_pwmclk_init();
|
||||
}
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
/* linux/arch/arm/mach-exynos4/cpu.c
|
||||
/* linux/arch/arm/mach-exynos/cpu.c
|
||||
*
|
||||
* Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
|
||||
* http://www.samsung.com
|
||||
|
|
@ -28,6 +28,7 @@
|
|||
#include <plat/fimc-core.h>
|
||||
#include <plat/iic-core.h>
|
||||
#include <plat/reset.h>
|
||||
#include <plat/tv-core.h>
|
||||
|
||||
#include <mach/regs-irq.h>
|
||||
#include <mach/regs-pmu.h>
|
||||
|
|
@ -39,27 +40,46 @@ extern int combiner_init(unsigned int combiner_nr, void __iomem *base,
|
|||
extern void combiner_cascade_irq(unsigned int combiner_nr, unsigned int irq);
|
||||
|
||||
/* Initial IO mappings */
|
||||
static struct map_desc exynos4_iodesc[] __initdata = {
|
||||
static struct map_desc exynos_iodesc[] __initdata = {
|
||||
{
|
||||
.virtual = (unsigned long)S5P_VA_SYSTIMER,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_SYSTIMER),
|
||||
.pfn = __phys_to_pfn(EXYNOS_PA_SYSTIMER),
|
||||
.length = SZ_4K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_CMU,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_CMU),
|
||||
.length = SZ_128K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_PMU,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_PMU),
|
||||
.pfn = __phys_to_pfn(EXYNOS_PA_PMU),
|
||||
.length = SZ_64K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_COMBINER_BASE,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_COMBINER),
|
||||
.pfn = __phys_to_pfn(EXYNOS_PA_COMBINER),
|
||||
.length = SZ_4K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_GIC_CPU,
|
||||
.pfn = __phys_to_pfn(EXYNOS_PA_GIC_CPU),
|
||||
.length = SZ_64K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_GIC_DIST,
|
||||
.pfn = __phys_to_pfn(EXYNOS_PA_GIC_DIST),
|
||||
.length = SZ_64K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S3C_VA_UART,
|
||||
.pfn = __phys_to_pfn(S3C_PA_UART),
|
||||
.length = SZ_512K,
|
||||
.type = MT_DEVICE,
|
||||
},
|
||||
};
|
||||
|
||||
static struct map_desc exynos4_iodesc[] __initdata = {
|
||||
{
|
||||
.virtual = (unsigned long)S5P_VA_CMU,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_CMU),
|
||||
.length = SZ_128K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_COREPERI_BASE,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
|
||||
|
|
@ -90,11 +110,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
|
|||
.pfn = __phys_to_pfn(EXYNOS4_PA_DMC0),
|
||||
.length = SZ_4K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S3C_VA_UART,
|
||||
.pfn = __phys_to_pfn(S3C_PA_UART),
|
||||
.length = SZ_512K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_SROMC,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_SROMC),
|
||||
|
|
@ -105,16 +120,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
|
|||
.pfn = __phys_to_pfn(EXYNOS4_PA_HSPHY),
|
||||
.length = SZ_4K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_GIC_CPU,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_GIC_CPU),
|
||||
.length = SZ_64K,
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = (unsigned long)S5P_VA_GIC_DIST,
|
||||
.pfn = __phys_to_pfn(EXYNOS4_PA_GIC_DIST),
|
||||
.length = SZ_64K,
|
||||
.type = MT_DEVICE,
|
||||
},
|
||||
};
|
||||
|
||||
|
|
@ -136,7 +141,7 @@ static struct map_desc exynos4_iodesc1[] __initdata = {
|
|||
},
|
||||
};
|
||||
|
||||
static void exynos4_idle(void)
|
||||
static void exynos_idle(void)
|
||||
{
|
||||
if (!need_resched())
|
||||
cpu_do_idle();
|
||||
|
|
@ -150,12 +155,13 @@ static void exynos4_sw_reset(void)
|
|||
}
|
||||
|
||||
/*
|
||||
* exynos4_map_io
|
||||
* exynos_map_io
|
||||
*
|
||||
* register the standard cpu IO areas
|
||||
*/
|
||||
void __init exynos4_map_io(void)
|
||||
{
|
||||
iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
|
||||
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
|
||||
|
||||
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0)
|
||||
|
|
@ -182,6 +188,7 @@ void __init exynos4_map_io(void)
|
|||
s3c_i2c2_setname("s3c2440-i2c");
|
||||
|
||||
s5p_fb_setname(0, "exynos4-fb");
|
||||
s5p_hdmi_setname("exynos4-hdmi");
|
||||
}
|
||||
|
||||
void __init exynos4_init_clocks(int xtal)
|
||||
|
|
@ -248,7 +255,6 @@ static int __init exynos4_core_init(void)
|
|||
{
|
||||
return sysdev_class_register(&exynos4_sysclass);
|
||||
}
|
||||
|
||||
core_initcall(exynos4_core_init);
|
||||
|
||||
#ifdef CONFIG_CACHE_L2X0
|
||||
|
|
@ -277,15 +283,16 @@ static int __init exynos4_l2x0_cache_init(void)
|
|||
early_initcall(exynos4_l2x0_cache_init);
|
||||
#endif
|
||||
|
||||
int __init exynos4_init(void)
|
||||
int __init exynos_init(void)
|
||||
{
|
||||
printk(KERN_INFO "EXYNOS4: Initializing architecture\n");
|
||||
printk(KERN_INFO "EXYNOS: Initializing architecture\n");
|
||||
|
||||
/* set idle function */
|
||||
pm_idle = exynos4_idle;
|
||||
pm_idle = exynos_idle;
|
||||
|
||||
/* set sw_reset function */
|
||||
s5p_reset_hook = exynos4_sw_reset;
|
||||
if (soc_is_exynos4210() || soc_is_exynos4212() || soc_is_exynos4412())
|
||||
s5p_reset_hook = exynos4_sw_reset;
|
||||
|
||||
return sysdev_register(&exynos4_sysdev);
|
||||
}
|
||||
|
|
@ -12,6 +12,7 @@
|
|||
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <linux/export.h>
|
||||
|
||||
#include <mach/map.h>
|
||||
#include <mach/irqs.h>
|
||||
|
|
@ -0,0 +1,250 @@
|
|||
/* linux/arch/arm/mach-exynos4/dma.c
|
||||
*
|
||||
* Copyright (c) 2011 Samsung Electronics Co., Ltd.
|
||||
* http://www.samsung.com
|
||||
*
|
||||
* Copyright (C) 2010 Samsung Electronics Co. Ltd.
|
||||
* Jaswinder Singh <jassi.brar@samsung.com>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <linux/amba/bus.h>
|
||||
#include <linux/amba/pl330.h>
|
||||
|
||||
#include <asm/irq.h>
|
||||
#include <plat/devs.h>
|
||||
#include <plat/irqs.h>
|
||||
|
||||
#include <mach/map.h>
|
||||
#include <mach/irqs.h>
|
||||
#include <mach/dma.h>
|
||||
|
||||
static u64 dma_dmamask = DMA_BIT_MASK(32);
|
||||
|
||||
struct dma_pl330_peri pdma0_peri[28] = {
|
||||
{
|
||||
.peri_id = (u8)DMACH_PCM0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM2_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM2_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_MSM_REQ0,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_MSM_REQ2,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI2_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI2_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0S_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART2_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART2_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART4_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART4_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS2_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS2_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS4_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS4_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_AC97_MICIN,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_AC97_PCMIN,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_AC97_PCMOUT,
|
||||
.rqtype = MEMTODEV,
|
||||
},
|
||||
};
|
||||
|
||||
struct dma_pl330_platdata exynos4_pdma0_pdata = {
|
||||
.nr_valid_peri = ARRAY_SIZE(pdma0_peri),
|
||||
.peri = pdma0_peri,
|
||||
};
|
||||
|
||||
struct amba_device exynos4_device_pdma0 = {
|
||||
.dev = {
|
||||
.init_name = "dma-pl330.0",
|
||||
.dma_mask = &dma_dmamask,
|
||||
.coherent_dma_mask = DMA_BIT_MASK(32),
|
||||
.platform_data = &exynos4_pdma0_pdata,
|
||||
},
|
||||
.res = {
|
||||
.start = EXYNOS4_PA_PDMA0,
|
||||
.end = EXYNOS4_PA_PDMA0 + SZ_4K,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
.irq = {IRQ_PDMA0, NO_IRQ},
|
||||
.periphid = 0x00041330,
|
||||
};
|
||||
|
||||
struct dma_pl330_peri pdma1_peri[25] = {
|
||||
{
|
||||
.peri_id = (u8)DMACH_PCM0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM1_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_PCM1_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_MSM_REQ1,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_MSM_REQ3,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI1_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SPI1_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0S_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S1_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_I2S1_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART0_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART0_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART1_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART1_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART3_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_UART3_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS1_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS1_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS3_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS3_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS5_RX,
|
||||
.rqtype = DEVTOMEM,
|
||||
}, {
|
||||
.peri_id = (u8)DMACH_SLIMBUS5_TX,
|
||||
.rqtype = MEMTODEV,
|
||||
},
|
||||
};
|
||||
|
||||
struct dma_pl330_platdata exynos4_pdma1_pdata = {
|
||||
.nr_valid_peri = ARRAY_SIZE(pdma1_peri),
|
||||
.peri = pdma1_peri,
|
||||
};
|
||||
|
||||
struct amba_device exynos4_device_pdma1 = {
|
||||
.dev = {
|
||||
.init_name = "dma-pl330.1",
|
||||
.dma_mask = &dma_dmamask,
|
||||
.coherent_dma_mask = DMA_BIT_MASK(32),
|
||||
.platform_data = &exynos4_pdma1_pdata,
|
||||
},
|
||||
.res = {
|
||||
.start = EXYNOS4_PA_PDMA1,
|
||||
.end = EXYNOS4_PA_PDMA1 + SZ_4K,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
.irq = {IRQ_PDMA1, NO_IRQ},
|
||||
.periphid = 0x00041330,
|
||||
};
|
||||
|
||||
static int __init exynos4_dma_init(void)
|
||||
{
|
||||
amba_device_register(&exynos4_device_pdma0, &iomem_resource);
|
||||
amba_device_register(&exynos4_device_pdma1, &iomem_resource);
|
||||
|
||||
return 0;
|
||||
}
|
||||
arch_initcall(exynos4_dma_init);
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче