Merge with /pub/scm/linux/kernel/git/torvalds/linux-2.6.git
This commit is contained in:
commit
e82b3aec8d
6
CREDITS
6
CREDITS
|
@ -3642,11 +3642,9 @@ S: Beaverton, OR 97005
|
|||
S: USA
|
||||
|
||||
N: Michal Wronski
|
||||
E: wrona@mat.uni.torun.pl
|
||||
W: http://www.mat.uni.torun.pl/~wrona
|
||||
E: Michal.Wronski@motorola.com
|
||||
D: POSIX message queues fs (with K. Benedyczak)
|
||||
S: ul. Teczowa 23/12
|
||||
S: 80-680 Gdansk-Sobieszewo
|
||||
S: Krakow
|
||||
S: Poland
|
||||
|
||||
N: Frank Xia
|
||||
|
|
|
@ -139,9 +139,14 @@ You'll probably want to upgrade.
|
|||
Ksymoops
|
||||
--------
|
||||
|
||||
If the unthinkable happens and your kernel oopses, you'll need a 2.4
|
||||
version of ksymoops to decode the report; see REPORTING-BUGS in the
|
||||
root of the Linux source for more information.
|
||||
If the unthinkable happens and your kernel oopses, you may need the
|
||||
ksymoops tool to decode it, but in most cases you don't.
|
||||
In the 2.6 kernel it is generally preferred to build the kernel with
|
||||
CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is
|
||||
(this also produces better output than ksymoops).
|
||||
If for some reason your kernel is not build with CONFIG_KALLSYMS and
|
||||
you have no way to rebuild and reproduce the Oops with that option, then
|
||||
you can still decode that Oops with ksymoops.
|
||||
|
||||
Module-Init-Tools
|
||||
-----------------
|
||||
|
|
|
@ -10,7 +10,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
|||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||
procfs-guide.xml writing_usb_driver.xml \
|
||||
sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml
|
||||
|
||||
###
|
||||
# The build process is as follows (targets):
|
||||
|
|
|
@ -306,7 +306,7 @@ an example.
|
|||
</para>
|
||||
<sect1><title>Journal Level</title>
|
||||
!Efs/jbd/journal.c
|
||||
!Efs/jbd/recovery.c
|
||||
!Ifs/jbd/recovery.c
|
||||
</sect1>
|
||||
<sect1><title>Transasction Level</title>
|
||||
!Efs/jbd/transaction.c
|
||||
|
|
|
@ -118,7 +118,7 @@ X!Ilib/string.c
|
|||
</sect1>
|
||||
<sect1><title>User Space Memory Access</title>
|
||||
!Iinclude/asm-i386/uaccess.h
|
||||
!Iarch/i386/lib/usercopy.c
|
||||
!Earch/i386/lib/usercopy.c
|
||||
</sect1>
|
||||
<sect1><title>More Memory Management Functions</title>
|
||||
!Iinclude/linux/rmap.h
|
||||
|
@ -174,7 +174,6 @@ X!Ilib/string.c
|
|||
<title>The Linux VFS</title>
|
||||
<sect1><title>The Filesystem types</title>
|
||||
!Iinclude/linux/fs.h
|
||||
!Einclude/linux/fs.h
|
||||
</sect1>
|
||||
<sect1><title>The Directory Cache</title>
|
||||
!Efs/dcache.c
|
||||
|
@ -239,9 +238,9 @@ X!Ilib/string.c
|
|||
<title>Network device support</title>
|
||||
<sect1><title>Driver Support</title>
|
||||
!Enet/core/dev.c
|
||||
</sect1>
|
||||
<sect1><title>8390 Based Network Cards</title>
|
||||
!Edrivers/net/8390.c
|
||||
!Enet/ethernet/eth.c
|
||||
!Einclude/linux/etherdevice.h
|
||||
!Enet/core/wireless.c
|
||||
</sect1>
|
||||
<sect1><title>Synchronous PPP</title>
|
||||
!Edrivers/net/wan/syncppp.c
|
||||
|
@ -266,7 +265,7 @@ X!Ekernel/module.c
|
|||
<chapter id="hardware">
|
||||
<title>Hardware Interfaces</title>
|
||||
<sect1><title>Interrupt Handling</title>
|
||||
!Ikernel/irq/manage.c
|
||||
!Ekernel/irq/manage.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Resources Management</title>
|
||||
|
@ -501,7 +500,7 @@ KAO -->
|
|||
!Edrivers/video/modedb.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Macintosh Video Mode Database</title>
|
||||
!Idrivers/video/macmodes.c
|
||||
!Edrivers/video/macmodes.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Fonts</title>
|
||||
<para>
|
||||
|
|
|
@ -0,0 +1,160 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
|
||||
<!ENTITY rapidio SYSTEM "rapidio.xml">
|
||||
]>
|
||||
|
||||
<book id="RapidIO-Guide">
|
||||
<bookinfo>
|
||||
<title>RapidIO Subsystem Guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Matt</firstname>
|
||||
<surname>Porter</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>mporter@kernel.crashing.org</email>
|
||||
<email>mporter@mvista.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2005</year>
|
||||
<holder>MontaVista Software, Inc.</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License version 2 as published by the Free Software Foundation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more details see the file COPYING in the source
|
||||
distribution of Linux.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="intro">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
RapidIO is a high speed switched fabric interconnect with
|
||||
features aimed at the embedded market. RapidIO provides
|
||||
support for memory-mapped I/O as well as message-based
|
||||
transactions over the switched fabric network. RapidIO has
|
||||
a standardized discovery mechanism not unlike the PCI bus
|
||||
standard that allows simple detection of devices in a
|
||||
network.
|
||||
</para>
|
||||
<para>
|
||||
This documentation is provided for developers intending
|
||||
to support RapidIO on new architectures, write new drivers,
|
||||
or to understand the subsystem internals.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="bugs">
|
||||
<title>Known Bugs and Limitations</title>
|
||||
|
||||
<sect1>
|
||||
<title>Bugs</title>
|
||||
<para>None. ;)</para>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Limitations</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para>Access/management of RapidIO memory regions is not supported</para></listitem>
|
||||
<listitem><para>Multiple host enumeration is not supported</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="drivers">
|
||||
<title>RapidIO driver interface</title>
|
||||
<para>
|
||||
Drivers are provided a set of calls in order
|
||||
to interface with the subsystem to gather info
|
||||
on devices, request/map memory region resources,
|
||||
and manage mailboxes/doorbells.
|
||||
</para>
|
||||
<sect1>
|
||||
<title>Functions</title>
|
||||
!Iinclude/linux/rio_drv.h
|
||||
!Edrivers/rapidio/rio-driver.c
|
||||
!Edrivers/rapidio/rio.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="internals">
|
||||
<title>Internals</title>
|
||||
|
||||
<para>
|
||||
This chapter contains the autogenerated documentation of the RapidIO
|
||||
subsystem.
|
||||
</para>
|
||||
|
||||
<sect1><title>Structures</title>
|
||||
!Iinclude/linux/rio.h
|
||||
</sect1>
|
||||
<sect1><title>Enumeration and Discovery</title>
|
||||
!Idrivers/rapidio/rio-scan.c
|
||||
</sect1>
|
||||
<sect1><title>Driver functionality</title>
|
||||
!Idrivers/rapidio/rio.c
|
||||
!Idrivers/rapidio/rio-access.c
|
||||
</sect1>
|
||||
<sect1><title>Device model support</title>
|
||||
!Idrivers/rapidio/rio-driver.c
|
||||
</sect1>
|
||||
<sect1><title>Sysfs support</title>
|
||||
!Idrivers/rapidio/rio-sysfs.c
|
||||
</sect1>
|
||||
<sect1><title>PPC32 support</title>
|
||||
!Iarch/ppc/kernel/rio.c
|
||||
!Earch/ppc/syslib/ppc85xx_rio.c
|
||||
!Iarch/ppc/syslib/ppc85xx_rio.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="credits">
|
||||
<title>Credits</title>
|
||||
<para>
|
||||
The following people have contributed to the RapidIO
|
||||
subsystem directly or indirectly:
|
||||
<orderedlist>
|
||||
<listitem><para>Matt Porter<email>mporter@kernel.crashing.org</email></para></listitem>
|
||||
<listitem><para>Randy Vinson<email>rvinson@mvista.com</email></para></listitem>
|
||||
<listitem><para>Dan Malek<email>dan@embeddedalley.com</email></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<para>
|
||||
The following people have contributed to this document:
|
||||
<orderedlist>
|
||||
<listitem><para>Matt Porter<email>mporter@kernel.crashing.org</email></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</chapter>
|
||||
</book>
|
|
@ -10,14 +10,22 @@
|
|||
This guide describes the basics of Message Signaled Interrupts (MSI),
|
||||
the advantages of using MSI over traditional interrupt mechanisms,
|
||||
and how to enable your driver to use MSI or MSI-X. Also included is
|
||||
a Frequently Asked Questions.
|
||||
a Frequently Asked Questions (FAQ) section.
|
||||
|
||||
1.1 Terminology
|
||||
|
||||
PCI devices can be single-function or multi-function. In either case,
|
||||
when this text talks about enabling or disabling MSI on a "device
|
||||
function," it is referring to one specific PCI device and function and
|
||||
not to all functions on a PCI device (unless the PCI device has only
|
||||
one function).
|
||||
|
||||
2. Copyright 2003 Intel Corporation
|
||||
|
||||
3. What is MSI/MSI-X?
|
||||
|
||||
Message Signaled Interrupt (MSI), as described in the PCI Local Bus
|
||||
Specification Revision 2.3 or latest, is an optional feature, and a
|
||||
Specification Revision 2.3 or later, is an optional feature, and a
|
||||
required feature for PCI Express devices. MSI enables a device function
|
||||
to request service by sending an Inbound Memory Write on its PCI bus to
|
||||
the FSB as a Message Signal Interrupt transaction. Because MSI is
|
||||
|
@ -27,7 +35,7 @@ supported.
|
|||
|
||||
A PCI device that supports MSI must also support pin IRQ assertion
|
||||
interrupt mechanism to provide backward compatibility for systems that
|
||||
do not support MSI. In Systems, which support MSI, the bus driver is
|
||||
do not support MSI. In systems which support MSI, the bus driver is
|
||||
responsible for initializing the message address and message data of
|
||||
the device function's MSI/MSI-X capability structure during device
|
||||
initial configuration.
|
||||
|
@ -61,17 +69,17 @@ over the MSI capability structure as described below.
|
|||
|
||||
- MSI and MSI-X both support per-vector masking. Per-vector
|
||||
masking is an optional extension of MSI but a required
|
||||
feature for MSI-X. Per-vector masking provides the kernel
|
||||
the ability to mask/unmask MSI when servicing its software
|
||||
interrupt service routing handler. If per-vector masking is
|
||||
feature for MSI-X. Per-vector masking provides the kernel the
|
||||
ability to mask/unmask a single MSI while running its
|
||||
interrupt service routine. If per-vector masking is
|
||||
not supported, then the device driver should provide the
|
||||
hardware/software synchronization to ensure that the device
|
||||
generates MSI when the driver wants it to do so.
|
||||
|
||||
4. Why use MSI?
|
||||
|
||||
As a benefit the simplification of board design, MSI allows board
|
||||
designers to remove out of band interrupt routing. MSI is another
|
||||
As a benefit to the simplification of board design, MSI allows board
|
||||
designers to remove out-of-band interrupt routing. MSI is another
|
||||
step towards a legacy-free environment.
|
||||
|
||||
Due to increasing pressure on chipset and processor packages to
|
||||
|
@ -87,7 +95,7 @@ support. As a result, the PCI Express technology requires MSI
|
|||
support for better interrupt performance.
|
||||
|
||||
Using MSI enables the device functions to support two or more
|
||||
vectors, which can be configured to target different CPU's to
|
||||
vectors, which can be configured to target different CPUs to
|
||||
increase scalability.
|
||||
|
||||
5. Configuring a driver to use MSI/MSI-X
|
||||
|
@ -119,13 +127,13 @@ pci_enable_msi() explicitly.
|
|||
|
||||
int pci_enable_msi(struct pci_dev *dev)
|
||||
|
||||
With this new API, any existing device driver, which like to have
|
||||
MSI enabled on its device function, must call this API to enable MSI
|
||||
With this new API, a device driver that wants to have MSI
|
||||
enabled on its device function must call this API to enable MSI.
|
||||
A successful call will initialize the MSI capability structure
|
||||
with ONE vector, regardless of whether a device function is
|
||||
capable of supporting multiple messages. This vector replaces the
|
||||
pre-assigned dev->irq with a new MSI vector. To avoid the conflict
|
||||
of new assigned vector with existing pre-assigned vector requires
|
||||
pre-assigned dev->irq with a new MSI vector. To avoid a conflict
|
||||
of the new assigned vector with existing pre-assigned vector requires
|
||||
a device driver to call this API before calling request_irq().
|
||||
|
||||
5.2.2 API pci_disable_msi
|
||||
|
@ -137,14 +145,14 @@ when a device driver is unloading. This API restores dev->irq with
|
|||
the pre-assigned IOAPIC vector and switches a device's interrupt
|
||||
mode to PCI pin-irq assertion/INTx emulation mode.
|
||||
|
||||
Note that a device driver should always call free_irq() on MSI vector
|
||||
it has done request_irq() on before calling this API. Failure to do
|
||||
so results a BUG_ON() and a device will be left with MSI enabled and
|
||||
Note that a device driver should always call free_irq() on the MSI vector
|
||||
that it has done request_irq() on before calling this API. Failure to do
|
||||
so results in a BUG_ON() and a device will be left with MSI enabled and
|
||||
leaks its vector.
|
||||
|
||||
5.2.3 MSI mode vs. legacy mode diagram
|
||||
|
||||
The below diagram shows the events, which switches the interrupt
|
||||
The below diagram shows the events which switch the interrupt
|
||||
mode on the MSI-capable device function between MSI mode and
|
||||
PIN-IRQ assertion mode.
|
||||
|
||||
|
@ -155,9 +163,9 @@ PIN-IRQ assertion mode.
|
|||
------------ pci_disable_msi ------------------------
|
||||
|
||||
|
||||
Figure 1.0 MSI Mode vs. Legacy Mode
|
||||
Figure 1. MSI Mode vs. Legacy Mode
|
||||
|
||||
In Figure 1.0, a device operates by default in legacy mode. Legacy
|
||||
In Figure 1, a device operates by default in legacy mode. Legacy
|
||||
in this context means PCI pin-irq assertion or PCI-Express INTx
|
||||
emulation. A successful MSI request (using pci_enable_msi()) switches
|
||||
a device's interrupt mode to MSI mode. A pre-assigned IOAPIC vector
|
||||
|
@ -166,11 +174,11 @@ assigned MSI vector will replace dev->irq.
|
|||
|
||||
To return back to its default mode, a device driver should always call
|
||||
pci_disable_msi() to undo the effect of pci_enable_msi(). Note that a
|
||||
device driver should always call free_irq() on MSI vector it has done
|
||||
request_irq() on before calling pci_disable_msi(). Failure to do so
|
||||
results a BUG_ON() and a device will be left with MSI enabled and
|
||||
device driver should always call free_irq() on the MSI vector it has
|
||||
done request_irq() on before calling pci_disable_msi(). Failure to do
|
||||
so results in a BUG_ON() and a device will be left with MSI enabled and
|
||||
leaks its vector. Otherwise, the PCI subsystem restores a device's
|
||||
dev->irq with a pre-assigned IOAPIC vector and marks released
|
||||
dev->irq with a pre-assigned IOAPIC vector and marks the released
|
||||
MSI vector as unused.
|
||||
|
||||
Once being marked as unused, there is no guarantee that the PCI
|
||||
|
@ -178,8 +186,8 @@ subsystem will reserve this MSI vector for a device. Depending on
|
|||
the availability of current PCI vector resources and the number of
|
||||
MSI/MSI-X requests from other drivers, this MSI may be re-assigned.
|
||||
|
||||
For the case where the PCI subsystem re-assigned this MSI vector
|
||||
another driver, a request to switching back to MSI mode may result
|
||||
For the case where the PCI subsystem re-assigns this MSI vector to
|
||||
another driver, a request to switch back to MSI mode may result
|
||||
in being assigned a different MSI vector or a failure if no more
|
||||
vectors are available.
|
||||
|
||||
|
@ -208,12 +216,12 @@ Unlike the function pci_enable_msi(), the function pci_enable_msix()
|
|||
does not replace the pre-assigned IOAPIC dev->irq with a new MSI
|
||||
vector because the PCI subsystem writes the 1:1 vector-to-entry mapping
|
||||
into the field vector of each element contained in a second argument.
|
||||
Note that the pre-assigned IO-APIC dev->irq is valid only if the device
|
||||
operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt of
|
||||
Note that the pre-assigned IOAPIC dev->irq is valid only if the device
|
||||
operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
|
||||
using dev->irq by the device driver to request for interrupt service
|
||||
may result unpredictabe behavior.
|
||||
|
||||
For each MSI-X vector granted, a device driver is responsible to call
|
||||
For each MSI-X vector granted, a device driver is responsible for calling
|
||||
other functions like request_irq(), enable_irq(), etc. to enable
|
||||
this vector with its corresponding interrupt service handler. It is
|
||||
a device driver's choice to assign all vectors with the same
|
||||
|
@ -224,13 +232,13 @@ service handler.
|
|||
|
||||
The PCI 3.0 specification has implementation notes that MMIO address
|
||||
space for a device's MSI-X structure should be isolated so that the
|
||||
software system can set different page for controlling accesses to
|
||||
the MSI-X structure. The implementation of MSI patch requires the PCI
|
||||
software system can set different pages for controlling accesses to the
|
||||
MSI-X structure. The implementation of MSI support requires the PCI
|
||||
subsystem, not a device driver, to maintain full control of the MSI-X
|
||||
table/MSI-X PBA and MMIO address space of the MSI-X table/MSI-X PBA.
|
||||
A device driver is prohibited from requesting the MMIO address space
|
||||
of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem will fail
|
||||
enabling MSI-X on its hardware device when it calls the function
|
||||
table/MSI-X PBA (Pending Bit Array) and MMIO address space of the MSI-X
|
||||
table/MSI-X PBA. A device driver is prohibited from requesting the MMIO
|
||||
address space of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem
|
||||
will fail enabling MSI-X on its hardware device when it calls the function
|
||||
pci_enable_msix().
|
||||
|
||||
5.3.2 Handling MSI-X allocation
|
||||
|
@ -274,9 +282,9 @@ For the case where fewer MSI-X vectors are allocated to a function
|
|||
than requested, the function pci_enable_msix() will return the
|
||||
maximum number of MSI-X vectors available to the caller. A device
|
||||
driver may re-send its request with fewer or equal vectors indicated
|
||||
in a return. For example, if a device driver requests 5 vectors, but
|
||||
the number of available vectors is 3 vectors, a value of 3 will be a
|
||||
return as a result of pci_enable_msix() call. A function could be
|
||||
in the return. For example, if a device driver requests 5 vectors, but
|
||||
the number of available vectors is 3 vectors, a value of 3 will be
|
||||
returned as a result of pci_enable_msix() call. A function could be
|
||||
designed for its driver to use only 3 MSI-X table entries as
|
||||
different combinations as ABC--, A-B-C, A--CB, etc. Note that this
|
||||
patch does not support multiple entries with the same vector. Such
|
||||
|
@ -285,49 +293,46 @@ as ABBCC, AABCC, BCCBA, etc will result as a failure by the function
|
|||
pci_enable_msix(). Below are the reasons why supporting multiple
|
||||
entries with the same vector is an undesirable solution.
|
||||
|
||||
- The PCI subsystem can not determine which entry, which
|
||||
generated the message, to mask/unmask MSI while handling
|
||||
- The PCI subsystem cannot determine the entry that
|
||||
generated the message to mask/unmask MSI while handling
|
||||
software driver ISR. Attempting to walk through all MSI-X
|
||||
table entries (2048 max) to mask/unmask any match vector
|
||||
is an undesirable solution.
|
||||
|
||||
- Walk through all MSI-X table entries (2048 max) to handle
|
||||
- Walking through all MSI-X table entries (2048 max) to handle
|
||||
SMP affinity of any match vector is an undesirable solution.
|
||||
|
||||
5.3.4 API pci_enable_msix
|
||||
|
||||
int pci_enable_msix(struct pci_dev *dev, u32 *entries, int nvec)
|
||||
int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
|
||||
|
||||
This API enables a device driver to request the PCI subsystem
|
||||
for enabling MSI-X messages on its hardware device. Depending on
|
||||
to enable MSI-X messages on its hardware device. Depending on
|
||||
the availability of PCI vectors resources, the PCI subsystem enables
|
||||
either all or nothing.
|
||||
either all or none of the requested vectors.
|
||||
|
||||
Argument dev points to the device (pci_dev) structure.
|
||||
Argument 'dev' points to the device (pci_dev) structure.
|
||||
|
||||
Argument entries is a pointer of unsigned integer type. The number of
|
||||
elements is indicated in argument nvec. The content of each element
|
||||
will be mapped to the following struct defined in /driver/pci/msi.h.
|
||||
Argument 'entries' is a pointer to an array of msix_entry structs.
|
||||
The number of entries is indicated in argument 'nvec'.
|
||||
struct msix_entry is defined in /driver/pci/msi.h:
|
||||
|
||||
struct msix_entry {
|
||||
u16 vector; /* kernel uses to write alloc vector */
|
||||
u16 entry; /* driver uses to specify entry */
|
||||
};
|
||||
|
||||
A device driver is responsible for initializing the field entry of
|
||||
each element with unique entry supported by MSI-X table. Otherwise,
|
||||
A device driver is responsible for initializing the field 'entry' of
|
||||
each element with a unique entry supported by MSI-X table. Otherwise,
|
||||
-EINVAL will be returned as a result. A successful return of zero
|
||||
indicates the PCI subsystem completes initializing each of requested
|
||||
indicates the PCI subsystem completed initializing each of the requested
|
||||
entries of the MSI-X table with message address and message data.
|
||||
Last but not least, the PCI subsystem will write the 1:1
|
||||
vector-to-entry mapping into the field vector of each element. A
|
||||
device driver is responsible of keeping track of allocated MSI-X
|
||||
vector-to-entry mapping into the field 'vector' of each element. A
|
||||
device driver is responsible for keeping track of allocated MSI-X
|
||||
vectors in its internal data structure.
|
||||
|
||||
Argument nvec is an integer indicating the number of messages
|
||||
requested.
|
||||
|
||||
A return of zero indicates that the number of MSI-X vectors is
|
||||
A return of zero indicates that the number of MSI-X vectors was
|
||||
successfully allocated. A return of greater than zero indicates
|
||||
MSI-X vector shortage. Or a return of less than zero indicates
|
||||
a failure. This failure may be a result of duplicate entries
|
||||
|
@ -341,12 +346,12 @@ void pci_disable_msix(struct pci_dev *dev)
|
|||
This API should always be used to undo the effect of pci_enable_msix()
|
||||
when a device driver is unloading. Note that a device driver should
|
||||
always call free_irq() on all MSI-X vectors it has done request_irq()
|
||||
on before calling this API. Failure to do so results a BUG_ON() and
|
||||
on before calling this API. Failure to do so results in a BUG_ON() and
|
||||
a device will be left with MSI-X enabled and leaks its vectors.
|
||||
|
||||
5.3.6 MSI-X mode vs. legacy mode diagram
|
||||
|
||||
The below diagram shows the events, which switches the interrupt
|
||||
The below diagram shows the events which switch the interrupt
|
||||
mode on the MSI-X capable device function between MSI-X mode and
|
||||
PIN-IRQ assertion mode (legacy).
|
||||
|
||||
|
@ -356,22 +361,22 @@ PIN-IRQ assertion mode (legacy).
|
|||
| | ===============> | |
|
||||
------------ pci_disable_msix ------------------------
|
||||
|
||||
Figure 2.0 MSI-X Mode vs. Legacy Mode
|
||||
Figure 2. MSI-X Mode vs. Legacy Mode
|
||||
|
||||
In Figure 2.0, a device operates by default in legacy mode. A
|
||||
In Figure 2, a device operates by default in legacy mode. A
|
||||
successful MSI-X request (using pci_enable_msix()) switches a
|
||||
device's interrupt mode to MSI-X mode. A pre-assigned IOAPIC vector
|
||||
stored in dev->irq will be saved by the PCI subsystem; however,
|
||||
unlike MSI mode, the PCI subsystem will not replace dev->irq with
|
||||
assigned MSI-X vector because the PCI subsystem already writes the 1:1
|
||||
vector-to-entry mapping into the field vector of each element
|
||||
vector-to-entry mapping into the field 'vector' of each element
|
||||
specified in second argument.
|
||||
|
||||
To return back to its default mode, a device driver should always call
|
||||
pci_disable_msix() to undo the effect of pci_enable_msix(). Note that
|
||||
a device driver should always call free_irq() on all MSI-X vectors it
|
||||
has done request_irq() on before calling pci_disable_msix(). Failure
|
||||
to do so results a BUG_ON() and a device will be left with MSI-X
|
||||
to do so results in a BUG_ON() and a device will be left with MSI-X
|
||||
enabled and leaks its vectors. Otherwise, the PCI subsystem switches a
|
||||
device function's interrupt mode from MSI-X mode to legacy mode and
|
||||
marks all allocated MSI-X vectors as unused.
|
||||
|
@ -383,53 +388,56 @@ MSI/MSI-X requests from other drivers, these MSI-X vectors may be
|
|||
re-assigned.
|
||||
|
||||
For the case where the PCI subsystem re-assigned these MSI-X vectors
|
||||
to other driver, a request to switching back to MSI-X mode may result
|
||||
to other drivers, a request to switch back to MSI-X mode may result
|
||||
being assigned with another set of MSI-X vectors or a failure if no
|
||||
more vectors are available.
|
||||
|
||||
5.4 Handling function implementng both MSI and MSI-X capabilities
|
||||
5.4 Handling function implementing both MSI and MSI-X capabilities
|
||||
|
||||
For the case where a function implements both MSI and MSI-X
|
||||
capabilities, the PCI subsystem enables a device to run either in MSI
|
||||
mode or MSI-X mode but not both. A device driver determines whether it
|
||||
wants MSI or MSI-X enabled on its hardware device. Once a device
|
||||
driver requests for MSI, for example, it is prohibited to request for
|
||||
driver requests for MSI, for example, it is prohibited from requesting
|
||||
MSI-X; in other words, a device driver is not permitted to ping-pong
|
||||
between MSI mod MSI-X mode during a run-time.
|
||||
|
||||
5.5 Hardware requirements for MSI/MSI-X support
|
||||
|
||||
MSI/MSI-X support requires support from both system hardware and
|
||||
individual hardware device functions.
|
||||
|
||||
5.5.1 System hardware support
|
||||
|
||||
Since the target of MSI address is the local APIC CPU, enabling
|
||||
MSI/MSI-X support in Linux kernel is dependent on whether existing
|
||||
system hardware supports local APIC. Users should verify their
|
||||
system whether it runs when CONFIG_X86_LOCAL_APIC=y.
|
||||
MSI/MSI-X support in the Linux kernel is dependent on whether existing
|
||||
system hardware supports local APIC. Users should verify that their
|
||||
system supports local APIC operation by testing that it runs when
|
||||
CONFIG_X86_LOCAL_APIC=y.
|
||||
|
||||
In SMP environment, CONFIG_X86_LOCAL_APIC is automatically set;
|
||||
however, in UP environment, users must manually set
|
||||
CONFIG_X86_LOCAL_APIC. Once CONFIG_X86_LOCAL_APIC=y, setting
|
||||
CONFIG_PCI_MSI enables the VECTOR based scheme and
|
||||
the option for MSI-capable device drivers to selectively enable
|
||||
MSI/MSI-X.
|
||||
CONFIG_PCI_MSI enables the VECTOR based scheme and the option for
|
||||
MSI-capable device drivers to selectively enable MSI/MSI-X.
|
||||
|
||||
Note that CONFIG_X86_IO_APIC setting is irrelevant because MSI/MSI-X
|
||||
vector is allocated new during runtime and MSI/MSI-X support does not
|
||||
depend on BIOS support. This key independency enables MSI/MSI-X
|
||||
support on future IOxAPIC free platform.
|
||||
support on future IOxAPIC free platforms.
|
||||
|
||||
5.5.2 Device hardware support
|
||||
|
||||
The hardware device function supports MSI by indicating the
|
||||
MSI/MSI-X capability structure on its PCI capability list. By
|
||||
default, this capability structure will not be initialized by
|
||||
the kernel to enable MSI during the system boot. In other words,
|
||||
the device function is running on its default pin assertion mode.
|
||||
Note that in many cases the hardware supporting MSI have bugs,
|
||||
which may result in system hang. The software driver of specific
|
||||
MSI-capable hardware is responsible for whether calling
|
||||
which may result in system hangs. The software driver of specific
|
||||
MSI-capable hardware is responsible for deciding whether to call
|
||||
pci_enable_msi or not. A return of zero indicates the kernel
|
||||
successfully initializes the MSI/MSI-X capability structure of the
|
||||
successfully initialized the MSI/MSI-X capability structure of the
|
||||
device function. The device function is now running on MSI/MSI-X mode.
|
||||
|
||||
5.6 How to tell whether MSI/MSI-X is enabled on device function
|
||||
|
@ -439,10 +447,10 @@ pci_enable_msi()/pci_enable_msix() indicates to a device driver that
|
|||
its device function is initialized successfully and ready to run in
|
||||
MSI/MSI-X mode.
|
||||
|
||||
At the user level, users can use command 'cat /proc/interrupts'
|
||||
to display the vector allocated for a device and its interrupt
|
||||
MSI/MSI-X mode ("PCI MSI"/"PCI MSIX"). Below shows below MSI mode is
|
||||
enabled on a SCSI Adaptec 39320D Ultra320.
|
||||
At the user level, users can use the command 'cat /proc/interrupts'
|
||||
to display the vectors allocated for devices and their interrupt
|
||||
MSI/MSI-X modes ("PCI-MSI"/"PCI-MSI-X"). Below shows MSI mode is
|
||||
enabled on a SCSI Adaptec 39320D Ultra320 controller.
|
||||
|
||||
CPU0 CPU1
|
||||
0: 324639 0 IO-APIC-edge timer
|
||||
|
@ -453,8 +461,8 @@ enabled on a SCSI Adaptec 39320D Ultra320.
|
|||
15: 1 0 IO-APIC-edge ide1
|
||||
169: 0 0 IO-APIC-level uhci-hcd
|
||||
185: 0 0 IO-APIC-level uhci-hcd
|
||||
193: 138 10 PCI MSI aic79xx
|
||||
201: 30 0 PCI MSI aic79xx
|
||||
193: 138 10 PCI-MSI aic79xx
|
||||
201: 30 0 PCI-MSI aic79xx
|
||||
225: 30 0 IO-APIC-level aic7xxx
|
||||
233: 30 0 IO-APIC-level aic7xxx
|
||||
NMI: 0 0
|
||||
|
@ -490,8 +498,8 @@ target address set as 0xfeexxxxx, as conformed to PCI
|
|||
specification 2.3 or latest, then it should work.
|
||||
|
||||
Q4. From the driver point of view, if the MSI is lost because
|
||||
of the errors occur during inbound memory write, then it may
|
||||
wait for ever. Is there a mechanism for it to recover?
|
||||
of errors occurring during inbound memory write, then it may
|
||||
wait forever. Is there a mechanism for it to recover?
|
||||
|
||||
A4. Since the target of the transaction is an inbound memory
|
||||
write, all transaction termination conditions (Retry,
|
||||
|
|
|
@ -772,8 +772,6 @@ RCU pointer/list traversal:
|
|||
list_for_each_entry_rcu
|
||||
list_for_each_continue_rcu (to be deprecated in favor of new
|
||||
list_for_each_entry_continue_rcu)
|
||||
hlist_for_each_rcu (to be deprecated in favor of
|
||||
hlist_for_each_entry_rcu)
|
||||
hlist_for_each_entry_rcu
|
||||
|
||||
RCU pointer update:
|
||||
|
|
|
@ -8,10 +8,9 @@ Compilation of kernel
|
|||
---------------------
|
||||
|
||||
In order to compile ARM Linux, you will need a compiler capable of
|
||||
generating ARM ELF code with GNU extensions. GCC 2.95.1, EGCS
|
||||
1.1.2, and GCC 3.3 are known to be good compilers. Fortunately, you
|
||||
needn't guess. The kernel will report an error if your compiler is
|
||||
a recognized offender.
|
||||
generating ARM ELF code with GNU extensions. GCC 3.3 is known to be
|
||||
a good compiler. Fortunately, you needn't guess. The kernel will report
|
||||
an error if your compiler is a recognized offender.
|
||||
|
||||
To build ARM Linux natively, you shouldn't have to alter the ARCH = line
|
||||
in the top level Makefile. However, if you don't have the ARM Linux ELF
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
#include <linux/skbuff.h>
|
||||
#include <linux/timer.h>
|
||||
|
||||
#include "connector.h"
|
||||
#include <linux/connector.h>
|
||||
|
||||
static struct cb_id cn_test_id = { 0x123, 0x456 };
|
||||
static char cn_test_name[] = "cn_test";
|
||||
|
@ -104,7 +104,7 @@ static int cn_test_want_notify(void)
|
|||
req->first = cn_test_id.val + 20;
|
||||
req->range = 10;
|
||||
|
||||
NETLINK_CB(skb).dst_groups = ctl->group;
|
||||
NETLINK_CB(skb).dst_group = ctl->group;
|
||||
//netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC);
|
||||
netlink_unicast(nls, skb, 0, 0);
|
||||
|
||||
|
|
|
@ -19,7 +19,6 @@ There are two dm targets available: snapshot and snapshot-origin.
|
|||
*) snapshot-origin <origin>
|
||||
|
||||
which will normally have one or more snapshots based on it.
|
||||
You must create the snapshot-origin device before you can create snapshots.
|
||||
Reads will be mapped directly to the backing device. For each write, the
|
||||
original data will be saved in the <COW device> of each snapshot to keep
|
||||
its visible content unchanged, at least until the <COW device> fills up.
|
||||
|
@ -27,7 +26,7 @@ its visible content unchanged, at least until the <COW device> fills up.
|
|||
|
||||
*) snapshot <origin> <COW device> <persistent?> <chunksize>
|
||||
|
||||
A snapshot is created of the <origin> block device. Changed chunks of
|
||||
A snapshot of the <origin> block device is created. Changed chunks of
|
||||
<chunksize> sectors will be stored on the <COW device>. Writes will
|
||||
only go to the <COW device>. Reads will come from the <COW device> or
|
||||
from <origin> for unchanged data. <COW device> will often be
|
||||
|
@ -37,6 +36,8 @@ the amount of free space and expand the <COW device> before it fills up.
|
|||
|
||||
<persistent?> is P (Persistent) or N (Not persistent - will not survive
|
||||
after reboot).
|
||||
The difference is that for transient snapshots less metadata must be
|
||||
saved on disk - they can be kept in memory by the kernel.
|
||||
|
||||
|
||||
How this is used by LVM2
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
How to get the Nebula, PCTV and Twinhan DST cards working
|
||||
=========================================================
|
||||
How to get the Nebula, PCTV, FusionHDTV Lite and Twinhan DST cards working
|
||||
==========================================================================
|
||||
|
||||
This class of cards has a bt878a as the PCI interface, and
|
||||
require the bttv driver.
|
||||
|
@ -26,27 +26,31 @@ Furthermore you need to enable
|
|||
|
||||
In general you need to load the bttv driver, which will handle the gpio and
|
||||
i2c communication for us, plus the common dvb-bt8xx device driver.
|
||||
The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and
|
||||
TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
|
||||
The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110), TwinHan (dst),
|
||||
FusionHDTV DVB-T Lite (mt352) and FusionHDTV5 Lite (lgdt330x) are loaded
|
||||
automatically by the dvb-bt8xx device driver.
|
||||
|
||||
3a) Nebula / Pinnacle PCTV
|
||||
--------------------------
|
||||
3a) Nebula / Pinnacle PCTV / FusionHDTV Lite
|
||||
---------------------------------------------
|
||||
|
||||
$ modprobe bttv (normally bttv is being loaded automatically by kmod)
|
||||
$ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)
|
||||
$ modprobe dvb-bt8xx
|
||||
|
||||
(or just place dvb-bt8xx in /etc/modules for automatic loading)
|
||||
|
||||
|
||||
3b) TwinHan and Clones
|
||||
--------------------------
|
||||
|
||||
$ modprobe bttv i2c_hw=1 card=0x71
|
||||
$ modprobe bttv card=0x71
|
||||
$ modprobe dvb-bt8xx
|
||||
$ modprobe dst
|
||||
|
||||
The value 0x71 will override the PCI type detection for dvb-bt8xx,
|
||||
which is necessary for TwinHan cards.
|
||||
which is necessary for TwinHan cards. Omission of this parameter might result
|
||||
in a system lockup.
|
||||
|
||||
If you're having an older card (blue color circuit) and card=0x71 locks
|
||||
If you're having an older card (blue color PCB) and card=0x71 locks up
|
||||
your machine, try using 0x68, too. If that does not work, ask on the
|
||||
mailing list.
|
||||
|
||||
|
@ -64,11 +68,47 @@ verbose=0 means complete disabling of messages
|
|||
dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card.
|
||||
0x20 means it has a Conditional Access slot.
|
||||
|
||||
The autodected values are determined bythe cards 'response
|
||||
string' which you can see in your logs e.g.
|
||||
The autodetected values are determined by the cards 'response string'
|
||||
which you can see in your logs e.g.
|
||||
|
||||
dst_get_device_id: Recognise [DSTMCI]
|
||||
|
||||
If you need to sent in bug reports on the dst, please do send in a complete
|
||||
log with the verbose=4 module parameter. For general usage, the default setting
|
||||
of verbose=1 is ideal.
|
||||
|
||||
|
||||
4) Multiple cards
|
||||
--------------------------
|
||||
|
||||
If you happen to be running multiple cards, it would be advisable to load
|
||||
the bttv module with the card id. This would help to solve any module loading
|
||||
problems that you might face.
|
||||
|
||||
For example, if you have a Twinhan and Clones card along with a FusionHDTV5 Lite
|
||||
|
||||
$ modprobe bttv card=0x71 card=0x87
|
||||
|
||||
Here the order of the card id is important and should be the same as that of the
|
||||
physical order of the cards. Here card=0x71 represents the Twinhan and clones
|
||||
and card=0x87 represents Fusion HDTV5 Lite. These arguments can also be
|
||||
specified in decimal, rather than hex:
|
||||
|
||||
$ modprobe bttv card=113 card=135
|
||||
|
||||
Some examples of card-id's
|
||||
|
||||
Pinnacle Sat 0x5e (94)
|
||||
Nebula Digi TV 0x68 (104)
|
||||
PC HDTV 0x70 (112)
|
||||
Twinhan 0x71 (113)
|
||||
FusionHDTV DVB-T Lite 0x80 (128)
|
||||
FusionHDTV5 Lite 0x87 (135)
|
||||
|
||||
For a full list of card-id's, see the V4L Documentation within the kernel
|
||||
source: linux/Documentation/video4linux/CARDLIST.bttv
|
||||
|
||||
If you have problems with this please do ask on the mailing list.
|
||||
|
||||
--
|
||||
Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham
|
||||
|
|
|
@ -41,6 +41,12 @@ o Frontends drivers:
|
|||
- dib3000mb : DiBcom 3000-MB demodulator
|
||||
DVB-S/C/T:
|
||||
- dst : TwinHan DST Frontend
|
||||
ATSC:
|
||||
- nxt200x : Nxtwave NXT2002 & NXT2004
|
||||
- or51211 : or51211 based (pcHDTV HD2000 card)
|
||||
- or51132 : or51132 based (pcHDTV HD3000 card)
|
||||
- bcm3510 : Broadcom BCM3510
|
||||
- lgdt330x : LG Electronics DT3302 & DT3303
|
||||
|
||||
|
||||
o Cards based on the Phillips saa7146 multimedia PCI bridge chip:
|
||||
|
@ -62,6 +68,10 @@ o Cards based on the Conexant Bt8xx PCI bridge:
|
|||
- Nebula Electronics DigiTV
|
||||
- TwinHan DST
|
||||
- Avermedia DVB-T
|
||||
- ChainTech digitop DST-1000 DVB-S
|
||||
- pcHDTV HD-2000 TV
|
||||
- DViCO FusionHDTV DVB-T Lite
|
||||
- DViCO FusionHDTV5 Lite
|
||||
|
||||
o Technotrend / Hauppauge DVB USB devices:
|
||||
- Nova USB
|
||||
|
@ -83,3 +93,30 @@ o DiBcom DVB-T USB based devices:
|
|||
- DiBcom USB2.0 DVB-T reference device (non-public)
|
||||
|
||||
o Experimental support for the analog module of the Siemens DVB-C PCI card
|
||||
|
||||
o Cards based on the Conexant cx2388x PCI bridge:
|
||||
- ADS Tech Instant TV DVB-T PCI
|
||||
- ATI HDTV Wonder
|
||||
- digitalnow DNTV Live! DVB-T
|
||||
- DViCO FusionHDTV DVB-T1
|
||||
- DViCO FusionHDTV DVB-T Plus
|
||||
- DViCO FusionHDTV3 Gold-Q
|
||||
- DViCO FusionHDTV3 Gold-T
|
||||
- DViCO FusionHDTV5 Gold
|
||||
- Hauppauge Nova-T DVB-T
|
||||
- KWorld/VStream XPert DVB-T
|
||||
- pcHDTV HD3000 HDTV
|
||||
- TerraTec Cinergy 1400 DVB-T
|
||||
- WinFast DTV1000-T
|
||||
|
||||
o Cards based on the Phillips saa7134 PCI bridge:
|
||||
- Medion 7134
|
||||
- Pinnacle PCTV 300i DVB-T + PAL
|
||||
- LifeView FlyDVB-T DUO
|
||||
- Typhoon DVB-T Duo Digital/Analog Cardbus
|
||||
- Philips TOUGH DVB-T reference design
|
||||
- Philips EUROPA V3 reference design
|
||||
- Compro Videomate DVB-T300
|
||||
- Compro Videomate DVB-T200
|
||||
- AVerMedia AVerTVHD MCE A180
|
||||
|
||||
|
|
|
@ -75,5 +75,22 @@ Ernst Peinlich <e.peinlich@inode.at>
|
|||
Peter Beutner <p.beutner@gmx.net>
|
||||
for the IR code for the ttusb-dec driver
|
||||
|
||||
Wilson Michaels <wilsonmichaels@earthlink.net>
|
||||
for the lgdt330x frontend driver, and various bugfixes
|
||||
|
||||
Michael Krufky <mkrufky@m1k.net>
|
||||
for maintaining v4l/dvb inter-tree dependencies
|
||||
|
||||
Taylor Jacob <rtjacob@earthlink.net>
|
||||
for the nxt2002 frontend driver
|
||||
|
||||
Jean-Francois Thibert <jeanfrancois@sagetv.com>
|
||||
for the nxt2004 frontend driver
|
||||
|
||||
Kirk Lapray <kirk.lapray@gmail.com>
|
||||
for the or51211 and or51132 frontend drivers, and
|
||||
for merging the nxt2002 and nxt2004 modules into a
|
||||
single nxt200x frontend driver.
|
||||
|
||||
(If you think you should be in this list, but you are not, drop a
|
||||
line to the DVB mailing list)
|
||||
|
|
|
@ -22,7 +22,7 @@ use File::Temp qw/ tempdir /;
|
|||
use IO::Handle;
|
||||
|
||||
@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t",
|
||||
"dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002",
|
||||
"dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb");
|
||||
|
||||
# Check args
|
||||
|
@ -252,6 +252,23 @@ sub nxt2002 {
|
|||
$outfile;
|
||||
}
|
||||
|
||||
sub nxt2004 {
|
||||
my $sourcefile = "AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip";
|
||||
my $url = "http://www.aver.com/support/Drivers/$sourcefile";
|
||||
my $hash = "111cb885b1e009188346d72acfed024c";
|
||||
my $outfile = "dvb-fe-nxt2004.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
||||
checkstandard();
|
||||
|
||||
wgetfile($sourcefile, $url);
|
||||
unzip($sourcefile, $tmpdir);
|
||||
verify("$tmpdir/3xHybrid.sys", $hash);
|
||||
extract("$tmpdir/3xHybrid.sys", 465304, 9584, $outfile);
|
||||
|
||||
$outfile;
|
||||
}
|
||||
|
||||
sub or51211 {
|
||||
my $fwfile = "dvb-fe-or51211.fw";
|
||||
my $url = "http://linuxtv.org/downloads/firmware/$fwfile";
|
||||
|
|
|
@ -0,0 +1,152 @@
|
|||
The Framebuffer Console
|
||||
=======================
|
||||
|
||||
The framebuffer console (fbcon), as its name implies, is a text
|
||||
console running on top of the framebuffer device. It has the functionality of
|
||||
any standard text console driver, such as the VGA console, with the added
|
||||
features that can be attributed to the graphical nature of the framebuffer.
|
||||
|
||||
In the x86 architecture, the framebuffer console is optional, and
|
||||
some even treat it as a toy. For other architectures, it is the only available
|
||||
display device, text or graphical.
|
||||
|
||||
What are the features of fbcon? The framebuffer console supports
|
||||
high resolutions, varying font types, display rotation, primitive multihead,
|
||||
etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature
|
||||
made available by the underlying graphics card are also possible.
|
||||
|
||||
A. Configuration
|
||||
|
||||
The framebuffer console can be enabled by using your favorite kernel
|
||||
configuration tool. It is under Device Drivers->Graphics Support->Support for
|
||||
framebuffer devices->Framebuffer Console Support. Select 'y' to compile
|
||||
support statically, or 'm' for module support. The module will be fbcon.
|
||||
|
||||
In order for fbcon to activate, at least one framebuffer driver is
|
||||
required, so choose from any of the numerous drivers available. For x86
|
||||
systems, they almost universally have VGA cards, so vga16fb and vesafb will
|
||||
always be available. However, using a chipset-specific driver will give you
|
||||
more speed and features, such as the ability to change the video mode
|
||||
dynamically.
|
||||
|
||||
To display the penguin logo, choose any logo available in Logo
|
||||
Configuration->Boot up logo.
|
||||
|
||||
Also, you will need to select at least one compiled-in fonts, but if
|
||||
you don't do anything, the kernel configuration tool will select one for you,
|
||||
usually an 8x16 font.
|
||||
|
||||
GOTCHA: A common bug report is enabling the framebuffer without enabling the
|
||||
framebuffer console. Depending on the driver, you may get a blanked or
|
||||
garbled display, but the system still boots to completion. If you are
|
||||
fortunate to have a driver that does not alter the graphics chip, then you
|
||||
will still get a VGA console.
|
||||
|
||||
B. Loading
|
||||
|
||||
Possible scenarios:
|
||||
|
||||
1. Driver and fbcon are compiled statically
|
||||
|
||||
Usually, fbcon will automatically take over your console. The notable
|
||||
exception is vesafb. It needs to be explicitly activated with the
|
||||
vga= boot option parameter.
|
||||
|
||||
2. Driver is compiled statically, fbcon is compiled as a module
|
||||
|
||||
Depending on the driver, you either get a standard console, or a
|
||||
garbled display, as mentioned above. To get a framebuffer console,
|
||||
do a 'modprobe fbcon'.
|
||||
|
||||
3. Driver is compiled as a module, fbcon is compiled statically
|
||||
|
||||
You get your standard console. Once the driver is loaded with
|
||||
'modprobe xxxfb', fbcon automatically takes over the console with
|
||||
the possible exception of using the fbcon=map:n option. See below.
|
||||
|
||||
4. Driver and fbcon are compiled as a module.
|
||||
|
||||
You can load them in any order. Once both are loaded, fbcon will take
|
||||
over the console.
|
||||
|
||||
C. Boot options
|
||||
|
||||
The framebuffer console has several, largely unknown, boot options
|
||||
that can change its behavior.
|
||||
|
||||
1. fbcon=font:<name>
|
||||
|
||||
Select the initial font to use. The value 'name' can be any of the
|
||||
compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,
|
||||
SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8.
|
||||
|
||||
Note, not all drivers can handle font with widths not divisible by 8,
|
||||
such as vga16fb.
|
||||
|
||||
2. fbcon=scrollback:<value>[k]
|
||||
|
||||
The scrollback buffer is memory that is used to preserve display
|
||||
contents that has already scrolled past your view. This is accessed
|
||||
by using the Shift-PageUp key combination. The value 'value' is any
|
||||
integer. It defaults to 32KB. The 'k' suffix is optional, and will
|
||||
multiply the 'value' by 1024.
|
||||
|
||||
3. fbcon=map:<0123>
|
||||
|
||||
This is an interesting option. It tells which driver gets mapped to
|
||||
which console. The value '0123' is a sequence that gets repeated until
|
||||
the total length is 64 which is the number of consoles available. In
|
||||
the above example, it is expanded to 012301230123... and the mapping
|
||||
will be:
|
||||
|
||||
tty | 1 2 3 4 5 6 7 8 9 ...
|
||||
fb | 0 1 2 3 0 1 2 3 0 ...
|
||||
|
||||
('cat /proc/fb' should tell you what the fb numbers are)
|
||||
|
||||
One side effect that may be useful is using a map value that exceeds
|
||||
the number of loaded fb drivers. For example, if only one driver is
|
||||
available, fb0, adding fbcon=map:1 tells fbcon not to take over the
|
||||
console.
|
||||
|
||||
Later on, when you want to map the console the to the framebuffer
|
||||
device, you can use the con2fbmap utility.
|
||||
|
||||
4. fbcon=vc:<n1>-<n2>
|
||||
|
||||
This option tells fbcon to take over only a range of consoles as
|
||||
specified by the values 'n1' and 'n2'. The rest of the consoles
|
||||
outside the given range will still be controlled by the standard
|
||||
console driver.
|
||||
|
||||
NOTE: For x86 machines, the standard console is the VGA console which
|
||||
is typically located on the same video card. Thus, the consoles that
|
||||
are controlled by the VGA console will be garbled.
|
||||
|
||||
4. fbcon=rotate:<n>
|
||||
|
||||
This option changes the orientation angle of the console display. The
|
||||
value 'n' accepts the following:
|
||||
|
||||
0 - normal orientation (0 degree)
|
||||
1 - clockwise orientation (90 degrees)
|
||||
2 - upside down orientation (180 degrees)
|
||||
3 - counterclockwise orientation (270 degrees)
|
||||
|
||||
The angle can be changed anytime afterwards by 'echoing' the same
|
||||
numbers to any one of the 2 attributes found in
|
||||
/sys/class/graphics/fb{x}
|
||||
|
||||
con_rotate - rotate the display of the active console
|
||||
con_rotate_all - rotate the display of all consoles
|
||||
|
||||
Console rotation will only become available if Console Rotation
|
||||
Support is compiled in your kernel.
|
||||
|
||||
NOTE: This is purely console rotation. Any other applications that
|
||||
use the framebuffer will remain at their 'normal'orientation.
|
||||
Actually, the underlying fb driver is totally ignorant of console
|
||||
rotation.
|
||||
|
||||
---
|
||||
Antonino Daplas <adaplas@pol.net>
|
|
@ -146,10 +146,10 @@ pmipal Use the protected mode interface for palette changes.
|
|||
|
||||
mtrr:n setup memory type range registers for the vesafb framebuffer
|
||||
where n:
|
||||
0 - disabled (equivalent to nomtrr)
|
||||
0 - disabled (equivalent to nomtrr) (default)
|
||||
1 - uncachable
|
||||
2 - write-back
|
||||
3 - write-combining (default)
|
||||
3 - write-combining
|
||||
4 - write-through
|
||||
|
||||
If you see the following in dmesg, choose the type that matches the
|
||||
|
|
|
@ -25,6 +25,13 @@ Who: Adrian Bunk <bunk@stusta.de>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: drivers depending on OBSOLETE_OSS_DRIVER
|
||||
When: January 2006
|
||||
Why: OSS drivers with ALSA replacements
|
||||
Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: RCU API moves to EXPORT_SYMBOL_GPL
|
||||
When: April 2006
|
||||
Files: include/linux/rcupdate.h, kernel/rcupdate.c
|
||||
|
@ -60,6 +67,21 @@ Who: Jody McIntyre <scjody@steamballoon.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
||||
When: July 2006
|
||||
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
|
||||
series. The old API have lots of drawbacks and don't provide enough
|
||||
means to work with all video and audio standards. The newer API is
|
||||
already available on the main drivers and should be used instead.
|
||||
Newer drivers should use v4l_compat_translate_ioctl function to handle
|
||||
old calls, replacing to newer ones.
|
||||
Decoder iocts are using internally to allow video drivers to
|
||||
communicate with video decoders. This should also be improved to allow
|
||||
V4L2 calls being translated into compatible internal ioctls.
|
||||
Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid
|
||||
When: November 2005
|
||||
Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c
|
||||
|
@ -69,6 +91,22 @@ Who: Grant Coady <gcoady@gmail.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: remove EXPORT_SYMBOL(panic_timeout)
|
||||
When: April 2006
|
||||
Files: kernel/panic.c
|
||||
Why: No modular usage in the kernel.
|
||||
Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: remove EXPORT_SYMBOL(insert_resource)
|
||||
When: April 2006
|
||||
Files: kernel/resource.c
|
||||
Why: No modular usage in the kernel.
|
||||
Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||
When: November 2005
|
||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
||||
|
@ -95,3 +133,10 @@ Why: This interface has been obsoleted by the new layer3-independent
|
|||
to link against API-compatible library on top of libnfnetlink_queue
|
||||
instead of the current 'libipq'.
|
||||
Who: Harald Welte <laforge@netfilter.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: EXPORT_SYMBOL(lookup_hash)
|
||||
When: January 2006
|
||||
Why: Too low-level interface. Use lookup_one_len or lookup_create instead.
|
||||
Who: Christoph Hellwig <hch@lst.de>
|
||||
|
|
|
@ -0,0 +1,173 @@
|
|||
RCU-based dcache locking model
|
||||
==============================
|
||||
|
||||
On many workloads, the most common operation on dcache is to look up a
|
||||
dentry, given a parent dentry and the name of the child. Typically,
|
||||
for every open(), stat() etc., the dentry corresponding to the
|
||||
pathname will be looked up by walking the tree starting with the first
|
||||
component of the pathname and using that dentry along with the next
|
||||
component to look up the next level and so on. Since it is a frequent
|
||||
operation for workloads like multiuser environments and web servers,
|
||||
it is important to optimize this path.
|
||||
|
||||
Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus in
|
||||
every component during path look-up. Since 2.5.10 onwards, fast-walk
|
||||
algorithm changed this by holding the dcache_lock at the beginning and
|
||||
walking as many cached path component dentries as possible. This
|
||||
significantly decreases the number of acquisition of
|
||||
dcache_lock. However it also increases the lock hold time
|
||||
significantly and affects performance in large SMP machines. Since
|
||||
2.5.62 kernel, dcache has been using a new locking model that uses RCU
|
||||
to make dcache look-up lock-free.
|
||||
|
||||
The current dcache locking model is not very different from the
|
||||
existing dcache locking model. Prior to 2.5.62 kernel, dcache_lock
|
||||
protected the hash chain, d_child, d_alias, d_lru lists as well as
|
||||
d_inode and several other things like mount look-up. RCU-based changes
|
||||
affect only the way the hash chain is protected. For everything else
|
||||
the dcache_lock must be taken for both traversing as well as
|
||||
updating. The hash chain updates too take the dcache_lock. The
|
||||
significant change is the way d_lookup traverses the hash chain, it
|
||||
doesn't acquire the dcache_lock for this and rely on RCU to ensure
|
||||
that the dentry has not been *freed*.
|
||||
|
||||
|
||||
Dcache locking details
|
||||
======================
|
||||
|
||||
For many multi-user workloads, open() and stat() on files are very
|
||||
frequently occurring operations. Both involve walking of path names to
|
||||
find the dentry corresponding to the concerned file. In 2.4 kernel,
|
||||
dcache_lock was held during look-up of each path component. Contention
|
||||
and cache-line bouncing of this global lock caused significant
|
||||
scalability problems. With the introduction of RCU in Linux kernel,
|
||||
this was worked around by making the look-up of path components during
|
||||
path walking lock-free.
|
||||
|
||||
|
||||
Safe lock-free look-up of dcache hash table
|
||||
===========================================
|
||||
|
||||
Dcache is a complex data structure with the hash table entries also
|
||||
linked together in other lists. In 2.4 kernel, dcache_lock protected
|
||||
all the lists. We applied RCU only on hash chain walking. The rest of
|
||||
the lists are still protected by dcache_lock. Some of the important
|
||||
changes are :
|
||||
|
||||
1. The deletion from hash chain is done using hlist_del_rcu() macro
|
||||
which doesn't initialize next pointer of the deleted dentry and
|
||||
this allows us to walk safely lock-free while a deletion is
|
||||
happening.
|
||||
|
||||
2. Insertion of a dentry into the hash table is done using
|
||||
hlist_add_head_rcu() which take care of ordering the writes - the
|
||||
writes to the dentry must be visible before the dentry is
|
||||
inserted. This works in conjunction with hlist_for_each_rcu() while
|
||||
walking the hash chain. The only requirement is that all
|
||||
initialization to the dentry must be done before
|
||||
hlist_add_head_rcu() since we don't have dcache_lock protection
|
||||
while traversing the hash chain. This isn't different from the
|
||||
existing code.
|
||||
|
||||
3. The dentry looked up without holding dcache_lock by cannot be
|
||||
returned for walking if it is unhashed. It then may have a NULL
|
||||
d_inode or other bogosity since RCU doesn't protect the other
|
||||
fields in the dentry. We therefore use a flag DCACHE_UNHASHED to
|
||||
indicate unhashed dentries and use this in conjunction with a
|
||||
per-dentry lock (d_lock). Once looked up without the dcache_lock,
|
||||
we acquire the per-dentry lock (d_lock) and check if the dentry is
|
||||
unhashed. If so, the look-up is failed. If not, the reference count
|
||||
of the dentry is increased and the dentry is returned.
|
||||
|
||||
4. Once a dentry is looked up, it must be ensured during the path walk
|
||||
for that component it doesn't go away. In pre-2.5.10 code, this was
|
||||
done holding a reference to the dentry. dcache_rcu does the same.
|
||||
In some sense, dcache_rcu path walking looks like the pre-2.5.10
|
||||
version.
|
||||
|
||||
5. All dentry hash chain updates must take the dcache_lock as well as
|
||||
the per-dentry lock in that order. dput() does this to ensure that
|
||||
a dentry that has just been looked up in another CPU doesn't get
|
||||
deleted before dget() can be done on it.
|
||||
|
||||
6. There are several ways to do reference counting of RCU protected
|
||||
objects. One such example is in ipv4 route cache where deferred
|
||||
freeing (using call_rcu()) is done as soon as the reference count
|
||||
goes to zero. This cannot be done in the case of dentries because
|
||||
tearing down of dentries require blocking (dentry_iput()) which
|
||||
isn't supported from RCU callbacks. Instead, tearing down of
|
||||
dentries happen synchronously in dput(), but actual freeing happens
|
||||
later when RCU grace period is over. This allows safe lock-free
|
||||
walking of the hash chains, but a matched dentry may have been
|
||||
partially torn down. The checking of DCACHE_UNHASHED flag with
|
||||
d_lock held detects such dentries and prevents them from being
|
||||
returned from look-up.
|
||||
|
||||
|
||||
Maintaining POSIX rename semantics
|
||||
==================================
|
||||
|
||||
Since look-up of dentries is lock-free, it can race against a
|
||||
concurrent rename operation. For example, during rename of file A to
|
||||
B, look-up of either A or B must succeed. So, if look-up of B happens
|
||||
after A has been removed from the hash chain but not added to the new
|
||||
hash chain, it may fail. Also, a comparison while the name is being
|
||||
written concurrently by a rename may result in false positive matches
|
||||
violating rename semantics. Issues related to race with rename are
|
||||
handled as described below :
|
||||
|
||||
1. Look-up can be done in two ways - d_lookup() which is safe from
|
||||
simultaneous renames and __d_lookup() which is not. If
|
||||
__d_lookup() fails, it must be followed up by a d_lookup() to
|
||||
correctly determine whether a dentry is in the hash table or
|
||||
not. d_lookup() protects look-ups using a sequence lock
|
||||
(rename_lock).
|
||||
|
||||
2. The name associated with a dentry (d_name) may be changed if a
|
||||
rename is allowed to happen simultaneously. To avoid memcmp() in
|
||||
__d_lookup() go out of bounds due to a rename and false positive
|
||||
comparison, the name comparison is done while holding the
|
||||
per-dentry lock. This prevents concurrent renames during this
|
||||
operation.
|
||||
|
||||
3. Hash table walking during look-up may move to a different bucket as
|
||||
the current dentry is moved to a different bucket due to rename.
|
||||
But we use hlists in dcache hash table and they are
|
||||
null-terminated. So, even if a dentry moves to a different bucket,
|
||||
hash chain walk will terminate. [with a list_head list, it may not
|
||||
since termination is when the list_head in the original bucket is
|
||||
reached]. Since we redo the d_parent check and compare name while
|
||||
holding d_lock, lock-free look-up will not race against d_move().
|
||||
|
||||
4. There can be a theoretical race when a dentry keeps coming back to
|
||||
original bucket due to double moves. Due to this look-up may
|
||||
consider that it has never moved and can end up in a infinite loop.
|
||||
But this is not any worse that theoretical livelocks we already
|
||||
have in the kernel.
|
||||
|
||||
|
||||
Important guidelines for filesystem developers related to dcache_rcu
|
||||
====================================================================
|
||||
|
||||
1. Existing dcache interfaces (pre-2.5.62) exported to filesystem
|
||||
don't change. Only dcache internal implementation changes. However
|
||||
filesystems *must not* delete from the dentry hash chains directly
|
||||
using the list macros like allowed earlier. They must use dcache
|
||||
APIs like d_drop() or __d_drop() depending on the situation.
|
||||
|
||||
2. d_flags is now protected by a per-dentry lock (d_lock). All access
|
||||
to d_flags must be protected by it.
|
||||
|
||||
3. For a hashed dentry, checking of d_count needs to be protected by
|
||||
d_lock.
|
||||
|
||||
|
||||
Papers and other documentation on dcache locking
|
||||
================================================
|
||||
|
||||
1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
|
||||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
|
||||
|
||||
|
|
@ -1812,11 +1812,6 @@ it may overflow the messages buffer, but try to get as much of it as
|
|||
you can
|
||||
|
||||
|
||||
if you get an Oops, run ksymoops to decode it so that the
|
||||
names of the offending functions are provided. A non-decoded Oops is
|
||||
pretty useless
|
||||
|
||||
|
||||
send a copy of your devfsd configuration file(s)
|
||||
|
||||
send the bug report to me first.
|
||||
|
|
|
@ -17,8 +17,6 @@ set using tune2fs(8). Kernel-determined defaults are indicated by (*).
|
|||
bsddf (*) Makes `df' act like BSD.
|
||||
minixdf Makes `df' act like Minix.
|
||||
|
||||
check Check block and inode bitmaps at mount time
|
||||
(requires CONFIG_EXT2_CHECK).
|
||||
check=none, nocheck (*) Don't do extra checking of bitmaps on mount
|
||||
(check=normal and check=strict options removed)
|
||||
|
||||
|
|
|
@ -0,0 +1,195 @@
|
|||
ramfs, rootfs and initramfs
|
||||
October 17, 2005
|
||||
Rob Landley <rob@landley.net>
|
||||
=============================
|
||||
|
||||
What is ramfs?
|
||||
--------------
|
||||
|
||||
Ramfs is a very simple filesystem that exports Linux's disk caching
|
||||
mechanisms (the page cache and dentry cache) as a dynamically resizable
|
||||
ram-based filesystem.
|
||||
|
||||
Normally all files are cached in memory by Linux. Pages of data read from
|
||||
backing store (usually the block device the filesystem is mounted on) are kept
|
||||
around in case it's needed again, but marked as clean (freeable) in case the
|
||||
Virtual Memory system needs the memory for something else. Similarly, data
|
||||
written to files is marked clean as soon as it has been written to backing
|
||||
store, but kept around for caching purposes until the VM reallocates the
|
||||
memory. A similar mechanism (the dentry cache) greatly speeds up access to
|
||||
directories.
|
||||
|
||||
With ramfs, there is no backing store. Files written into ramfs allocate
|
||||
dentries and page cache as usual, but there's nowhere to write them to.
|
||||
This means the pages are never marked clean, so they can't be freed by the
|
||||
VM when it's looking to recycle memory.
|
||||
|
||||
The amount of code required to implement ramfs is tiny, because all the
|
||||
work is done by the existing Linux caching infrastructure. Basically,
|
||||
you're mounting the disk cache as a filesystem. Because of this, ramfs is not
|
||||
an optional component removable via menuconfig, since there would be negligible
|
||||
space savings.
|
||||
|
||||
ramfs and ramdisk:
|
||||
------------------
|
||||
|
||||
The older "ram disk" mechanism created a synthetic block device out of
|
||||
an area of ram and used it as backing store for a filesystem. This block
|
||||
device was of fixed size, so the filesystem mounted on it was of fixed
|
||||
size. Using a ram disk also required unnecessarily copying memory from the
|
||||
fake block device into the page cache (and copying changes back out), as well
|
||||
as creating and destroying dentries. Plus it needed a filesystem driver
|
||||
(such as ext2) to format and interpret this data.
|
||||
|
||||
Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
|
||||
unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks
|
||||
to avoid this copying by playing with the page tables, but they're unpleasantly
|
||||
complicated and turn out to be about as expensive as the copying anyway.)
|
||||
More to the point, all the work ramfs is doing has to happen _anyway_,
|
||||
since all file access goes through the page and dentry caches. The ram
|
||||
disk is simply unnecessary, ramfs is internally much simpler.
|
||||
|
||||
Another reason ramdisks are semi-obsolete is that the introduction of
|
||||
loopback devices offered a more flexible and convenient way to create
|
||||
synthetic block devices, now from files instead of from chunks of memory.
|
||||
See losetup (8) for details.
|
||||
|
||||
ramfs and tmpfs:
|
||||
----------------
|
||||
|
||||
One downside of ramfs is you can keep writing data into it until you fill
|
||||
up all memory, and the VM can't free it because the VM thinks that files
|
||||
should get written to backing store (rather than swap space), but ramfs hasn't
|
||||
got any backing store. Because of this, only root (or a trusted user) should
|
||||
be allowed write access to a ramfs mount.
|
||||
|
||||
A ramfs derivative called tmpfs was created to add size limits, and the ability
|
||||
to write the data to swap space. Normal users can be allowed write access to
|
||||
tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.
|
||||
|
||||
What is rootfs?
|
||||
---------------
|
||||
|
||||
Rootfs is a special instance of ramfs, which is always present in 2.6 systems.
|
||||
(It's used internally as the starting and stopping point for searches of the
|
||||
kernel's doubly-linked list of mount points.)
|
||||
|
||||
Most systems just mount another filesystem over it and ignore it. The
|
||||
amount of space an empty instance of ramfs takes up is tiny.
|
||||
|
||||
What is initramfs?
|
||||
------------------
|
||||
|
||||
All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
|
||||
extracted into rootfs when the kernel boots up. After extracting, the kernel
|
||||
checks to see if rootfs contains a file "init", and if so it executes it as PID
|
||||
1. If found, this init process is responsible for bringing the system the
|
||||
rest of the way up, including locating and mounting the real root device (if
|
||||
any). If rootfs does not contain an init program after the embedded cpio
|
||||
archive is extracted into it, the kernel will fall through to the older code
|
||||
to locate and mount a root partition, then exec some variant of /sbin/init
|
||||
out of that.
|
||||
|
||||
All this differs from the old initrd in several ways:
|
||||
|
||||
- The old initrd was a separate file, while the initramfs archive is linked
|
||||
into the linux kernel image. (The directory linux-*/usr is devoted to
|
||||
generating this archive during the build.)
|
||||
|
||||
- The old initrd file was a gzipped filesystem image (in some file format,
|
||||
such as ext2, that had to be built into the kernel), while the new
|
||||
initramfs archive is a gzipped cpio archive (like tar only simpler,
|
||||
see cpio(1) and Documentation/early-userspace/buffer-format.txt).
|
||||
|
||||
- The program run by the old initrd (which was called /initrd, not /init) did
|
||||
some setup and then returned to the kernel, while the init program from
|
||||
initramfs is not expected to return to the kernel. (If /init needs to hand
|
||||
off control it can overmount / with a new root device and exec another init
|
||||
program. See the switch_root utility, below.)
|
||||
|
||||
- When switching another root device, initrd would pivot_root and then
|
||||
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
|
||||
rootfs, nor unmount it. Instead delete everything out of rootfs to
|
||||
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
|
||||
with the new root (cd /newmount; mount --move . /; chroot .), attach
|
||||
stdin/stdout/stderr to the new /dev/console, and exec the new init.
|
||||
|
||||
Since this is a remarkably persnickity process (and involves deleting
|
||||
commands before you can run them), the klibc package introduced a helper
|
||||
program (utils/run_init.c) to do all this for you. Most other packages
|
||||
(such as busybox) have named this command "switch_root".
|
||||
|
||||
Populating initramfs:
|
||||
---------------------
|
||||
|
||||
The 2.6 kernel build process always creates a gzipped cpio format initramfs
|
||||
archive and links it into the resulting kernel binary. By default, this
|
||||
archive is empty (consuming 134 bytes on x86). The config option
|
||||
CONFIG_INITRAMFS_SOURCE (for some reason buried under devices->block devices
|
||||
in menuconfig, and living in usr/Kconfig) can be used to specify a source for
|
||||
the initramfs archive, which will automatically be incorporated into the
|
||||
resulting binary. This option can point to an existing gzipped cpio archive, a
|
||||
directory containing files to be archived, or a text file specification such
|
||||
as the following example:
|
||||
|
||||
dir /dev 755 0 0
|
||||
nod /dev/console 644 0 0 c 5 1
|
||||
nod /dev/loop0 644 0 0 b 7 0
|
||||
dir /bin 755 1000 1000
|
||||
slink /bin/sh busybox 777 0 0
|
||||
file /bin/busybox initramfs/busybox 755 0 0
|
||||
dir /proc 755 0 0
|
||||
dir /sys 755 0 0
|
||||
dir /mnt 755 0 0
|
||||
file /init initramfs/init.sh 755 0 0
|
||||
|
||||
One advantage of the text file is that root access is not required to
|
||||
set permissions or create device nodes in the new archive. (Note that those
|
||||
two example "file" entries expect to find files named "init.sh" and "busybox" in
|
||||
a directory called "initramfs", under the linux-2.6.* directory. See
|
||||
Documentation/early-userspace/README for more details.)
|
||||
|
||||
If you don't already understand what shared libraries, devices, and paths
|
||||
you need to get a minimal root filesystem up and running, here are some
|
||||
references:
|
||||
http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
|
||||
http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
|
||||
http://www.linuxfromscratch.org/lfs/view/stable/
|
||||
|
||||
The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is
|
||||
designed to be a tiny C library to statically link early userspace
|
||||
code against, along with some related utilities. It is BSD licensed.
|
||||
|
||||
I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
|
||||
myself. These are LGPL and GPL, respectively.
|
||||
|
||||
In theory you could use glibc, but that's not well suited for small embedded
|
||||
uses like this. (A "hello world" program statically linked against glibc is
|
||||
over 400k. With uClibc it's 7k. Also note that glibc dlopens libnss to do
|
||||
name lookups, even when otherwise statically linked.)
|
||||
|
||||
Future directions:
|
||||
------------------
|
||||
|
||||
Today (2.6.14), initramfs is always compiled in, but not always used. The
|
||||
kernel falls back to legacy boot code that is reached only if initramfs does
|
||||
not contain an /init program. The fallback is legacy code, there to ensure a
|
||||
smooth transition and allowing early boot functionality to gradually move to
|
||||
"early userspace" (I.E. initramfs).
|
||||
|
||||
The move to early userspace is necessary because finding and mounting the real
|
||||
root device is complex. Root partitions can span multiple devices (raid or
|
||||
separate journal). They can be out on the network (requiring dhcp, setting a
|
||||
specific mac address, logging into a server, etc). They can live on removable
|
||||
media, with dynamically allocated major/minor numbers and persistent naming
|
||||
issues requiring a full udev implementation to sort out. They can be
|
||||
compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
|
||||
and so on.
|
||||
|
||||
This kind of complexity (which inevitably includes policy) is rightly handled
|
||||
in userspace. Both klibc and busybox/uClibc are working on simple initramfs
|
||||
packages to drop into a kernel build, and when standard solutions are ready
|
||||
and widely deployed, the kernel's legacy early boot code will become obsolete
|
||||
and a candidate for the feature removal schedule.
|
||||
|
||||
But that's a while off yet.
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Original author: Richard Gooch <rgooch@atnf.csiro.au>
|
||||
|
||||
Last updated on August 25, 2005
|
||||
Last updated on October 28, 2005
|
||||
|
||||
Copyright (C) 1999 Richard Gooch
|
||||
Copyright (C) 2005 Pekka Enberg
|
||||
|
@ -11,62 +11,61 @@
|
|||
This file is released under the GPLv2.
|
||||
|
||||
|
||||
What is it?
|
||||
===========
|
||||
Introduction
|
||||
============
|
||||
|
||||
The Virtual File System (otherwise known as the Virtual Filesystem
|
||||
Switch) is the software layer in the kernel that provides the
|
||||
filesystem interface to userspace programs. It also provides an
|
||||
abstraction within the kernel which allows different filesystem
|
||||
implementations to coexist.
|
||||
The Virtual File System (also known as the Virtual Filesystem Switch)
|
||||
is the software layer in the kernel that provides the filesystem
|
||||
interface to userspace programs. It also provides an abstraction
|
||||
within the kernel which allows different filesystem implementations to
|
||||
coexist.
|
||||
|
||||
VFS system calls open(2), stat(2), read(2), write(2), chmod(2) and so
|
||||
on are called from a process context. Filesystem locking is described
|
||||
in the document Documentation/filesystems/Locking.
|
||||
|
||||
|
||||
A Quick Look At How It Works
|
||||
============================
|
||||
Directory Entry Cache (dcache)
|
||||
------------------------------
|
||||
|
||||
In this section I'll briefly describe how things work, before
|
||||
launching into the details. I'll start with describing what happens
|
||||
when user programs open and manipulate files, and then look from the
|
||||
other view which is how a filesystem is supported and subsequently
|
||||
mounted.
|
||||
The VFS implements the open(2), stat(2), chmod(2), and similar system
|
||||
calls. The pathname argument that is passed to them is used by the VFS
|
||||
to search through the directory entry cache (also known as the dentry
|
||||
cache or dcache). This provides a very fast look-up mechanism to
|
||||
translate a pathname (filename) into a specific dentry. Dentries live
|
||||
in RAM and are never saved to disc: they exist only for performance.
|
||||
|
||||
The dentry cache is meant to be a view into your entire filespace. As
|
||||
most computers cannot fit all dentries in the RAM at the same time,
|
||||
some bits of the cache are missing. In order to resolve your pathname
|
||||
into a dentry, the VFS may have to resort to creating dentries along
|
||||
the way, and then loading the inode. This is done by looking up the
|
||||
inode.
|
||||
|
||||
|
||||
Opening a File
|
||||
--------------
|
||||
The Inode Object
|
||||
----------------
|
||||
|
||||
The VFS implements the open(2), stat(2), chmod(2) and similar system
|
||||
calls. The pathname argument is used by the VFS to search through the
|
||||
directory entry cache (dentry cache or "dcache"). This provides a very
|
||||
fast look-up mechanism to translate a pathname (filename) into a
|
||||
specific dentry.
|
||||
An individual dentry usually has a pointer to an inode. Inodes are
|
||||
filesystem objects such as regular files, directories, FIFOs and other
|
||||
beasts. They live either on the disc (for block device filesystems)
|
||||
or in the memory (for pseudo filesystems). Inodes that live on the
|
||||
disc are copied into the memory when required and changes to the inode
|
||||
are written back to disc. A single inode can be pointed to by multiple
|
||||
dentries (hard links, for example, do this).
|
||||
|
||||
An individual dentry usually has a pointer to an inode. Inodes are the
|
||||
things that live on disc drives, and can be regular files (you know:
|
||||
those things that you write data into), directories, FIFOs and other
|
||||
beasts. Dentries live in RAM and are never saved to disc: they exist
|
||||
only for performance. Inodes live on disc and are copied into memory
|
||||
when required. Later any changes are written back to disc. The inode
|
||||
that lives in RAM is a VFS inode, and it is this which the dentry
|
||||
points to. A single inode can be pointed to by multiple dentries
|
||||
(think about hardlinks).
|
||||
To look up an inode requires that the VFS calls the lookup() method of
|
||||
the parent directory inode. This method is installed by the specific
|
||||
filesystem implementation that the inode lives in. Once the VFS has
|
||||
the required dentry (and hence the inode), we can do all those boring
|
||||
things like open(2) the file, or stat(2) it to peek at the inode
|
||||
data. The stat(2) operation is fairly simple: once the VFS has the
|
||||
dentry, it peeks at the inode data and passes some of it back to
|
||||
userspace.
|
||||
|
||||
The dcache is meant to be a view into your entire filespace. Unlike
|
||||
Linus, most of us losers can't fit enough dentries into RAM to cover
|
||||
all of our filespace, so the dcache has bits missing. In order to
|
||||
resolve your pathname into a dentry, the VFS may have to resort to
|
||||
creating dentries along the way, and then loading the inode. This is
|
||||
done by looking up the inode.
|
||||
|
||||
To look up an inode (usually read from disc) requires that the VFS
|
||||
calls the lookup() method of the parent directory inode. This method
|
||||
is installed by the specific filesystem implementation that the inode
|
||||
lives in. There will be more on this later.
|
||||
|
||||
Once the VFS has the required dentry (and hence the inode), we can do
|
||||
all those boring things like open(2) the file, or stat(2) it to peek
|
||||
at the inode data. The stat(2) operation is fairly simple: once the
|
||||
VFS has the dentry, it peeks at the inode data and passes some of it
|
||||
back to userspace.
|
||||
The File Object
|
||||
---------------
|
||||
|
||||
Opening a file requires another operation: allocation of a file
|
||||
structure (this is the kernel-side implementation of file
|
||||
|
@ -74,51 +73,39 @@ descriptors). The freshly allocated file structure is initialized with
|
|||
a pointer to the dentry and a set of file operation member functions.
|
||||
These are taken from the inode data. The open() file method is then
|
||||
called so the specific filesystem implementation can do it's work. You
|
||||
can see that this is another switch performed by the VFS.
|
||||
|
||||
The file structure is placed into the file descriptor table for the
|
||||
process.
|
||||
can see that this is another switch performed by the VFS. The file
|
||||
structure is placed into the file descriptor table for the process.
|
||||
|
||||
Reading, writing and closing files (and other assorted VFS operations)
|
||||
is done by using the userspace file descriptor to grab the appropriate
|
||||
file structure, and then calling the required file structure method
|
||||
function to do whatever is required.
|
||||
|
||||
For as long as the file is open, it keeps the dentry "open" (in use),
|
||||
which in turn means that the VFS inode is still in use.
|
||||
|
||||
All VFS system calls (i.e. open(2), stat(2), read(2), write(2),
|
||||
chmod(2) and so on) are called from a process context. You should
|
||||
assume that these calls are made without any kernel locks being
|
||||
held. This means that the processes may be executing the same piece of
|
||||
filesystem or driver code at the same time, on different
|
||||
processors. You should ensure that access to shared resources is
|
||||
protected by appropriate locks.
|
||||
file structure, and then calling the required file structure method to
|
||||
do whatever is required. For as long as the file is open, it keeps the
|
||||
dentry in use, which in turn means that the VFS inode is still in use.
|
||||
|
||||
|
||||
Registering and Mounting a Filesystem
|
||||
-------------------------------------
|
||||
=====================================
|
||||
|
||||
If you want to support a new kind of filesystem in the kernel, all you
|
||||
need to do is call register_filesystem(). You pass a structure
|
||||
describing the filesystem implementation (struct file_system_type)
|
||||
which is then added to an internal table of supported filesystems. You
|
||||
can do:
|
||||
To register and unregister a filesystem, use the following API
|
||||
functions:
|
||||
|
||||
% cat /proc/filesystems
|
||||
#include <linux/fs.h>
|
||||
|
||||
to see what filesystems are currently available on your system.
|
||||
extern int register_filesystem(struct file_system_type *);
|
||||
extern int unregister_filesystem(struct file_system_type *);
|
||||
|
||||
When a request is made to mount a block device onto a directory in
|
||||
your filespace the VFS will call the appropriate method for the
|
||||
specific filesystem. The dentry for the mount point will then be
|
||||
updated to point to the root inode for the new filesystem.
|
||||
The passed struct file_system_type describes your filesystem. When a
|
||||
request is made to mount a device onto a directory in your filespace,
|
||||
the VFS will call the appropriate get_sb() method for the specific
|
||||
filesystem. The dentry for the mount point will then be updated to
|
||||
point to the root inode for the new filesystem.
|
||||
|
||||
It's now time to look at things in more detail.
|
||||
You can see all filesystems that are registered to the kernel in the
|
||||
file /proc/filesystems.
|
||||
|
||||
|
||||
struct file_system_type
|
||||
=======================
|
||||
-----------------------
|
||||
|
||||
This describes the filesystem. As of kernel 2.6.13, the following
|
||||
members are defined:
|
||||
|
@ -197,8 +184,14 @@ A fill_super() method implementation has the following arguments:
|
|||
int silent: whether or not to be silent on error
|
||||
|
||||
|
||||
The Superblock Object
|
||||
=====================
|
||||
|
||||
A superblock object represents a mounted filesystem.
|
||||
|
||||
|
||||
struct super_operations
|
||||
=======================
|
||||
-----------------------
|
||||
|
||||
This describes how the VFS can manipulate the superblock of your
|
||||
filesystem. As of kernel 2.6.13, the following members are defined:
|
||||
|
@ -286,9 +279,9 @@ or bottom half).
|
|||
a superblock. The second parameter indicates whether the method
|
||||
should wait until the write out has been completed. Optional.
|
||||
|
||||
write_super_lockfs: called when VFS is locking a filesystem and forcing
|
||||
it into a consistent state. This function is currently used by the
|
||||
Logical Volume Manager (LVM).
|
||||
write_super_lockfs: called when VFS is locking a filesystem and
|
||||
forcing it into a consistent state. This method is currently
|
||||
used by the Logical Volume Manager (LVM).
|
||||
|
||||
unlockfs: called when VFS is unlocking a filesystem and making it writable
|
||||
again.
|
||||
|
@ -317,8 +310,14 @@ field. This is a pointer to a "struct inode_operations" which
|
|||
describes the methods that can be performed on individual inodes.
|
||||
|
||||
|
||||
The Inode Object
|
||||
================
|
||||
|
||||
An inode object represents an object within the filesystem.
|
||||
|
||||
|
||||
struct inode_operations
|
||||
=======================
|
||||
-----------------------
|
||||
|
||||
This describes how the VFS can manipulate an inode in your
|
||||
filesystem. As of kernel 2.6.13, the following members are defined:
|
||||
|
@ -394,51 +393,62 @@ otherwise noted.
|
|||
will probably need to call d_instantiate() just as you would
|
||||
in the create() method
|
||||
|
||||
rename: called by the rename(2) system call to rename the object to
|
||||
have the parent and name given by the second inode and dentry.
|
||||
|
||||
readlink: called by the readlink(2) system call. Only required if
|
||||
you want to support reading symbolic links
|
||||
|
||||
follow_link: called by the VFS to follow a symbolic link to the
|
||||
inode it points to. Only required if you want to support
|
||||
symbolic links. This function returns a void pointer cookie
|
||||
symbolic links. This method returns a void pointer cookie
|
||||
that is passed to put_link().
|
||||
|
||||
put_link: called by the VFS to release resources allocated by
|
||||
follow_link(). The cookie returned by follow_link() is passed to
|
||||
to this function as the last parameter. It is used by filesystems
|
||||
such as NFS where page cache is not stable (i.e. page that was
|
||||
installed when the symbolic link walk started might not be in the
|
||||
page cache at the end of the walk).
|
||||
follow_link(). The cookie returned by follow_link() is passed
|
||||
to to this method as the last parameter. It is used by
|
||||
filesystems such as NFS where page cache is not stable
|
||||
(i.e. page that was installed when the symbolic link walk
|
||||
started might not be in the page cache at the end of the
|
||||
walk).
|
||||
|
||||
truncate: called by the VFS to change the size of a file. The i_size
|
||||
field of the inode is set to the desired size by the VFS before
|
||||
this function is called. This function is called by the truncate(2)
|
||||
system call and related functionality.
|
||||
truncate: called by the VFS to change the size of a file. The
|
||||
i_size field of the inode is set to the desired size by the
|
||||
VFS before this method is called. This method is called by
|
||||
the truncate(2) system call and related functionality.
|
||||
|
||||
permission: called by the VFS to check for access rights on a POSIX-like
|
||||
filesystem.
|
||||
|
||||
setattr: called by the VFS to set attributes for a file. This function is
|
||||
called by chmod(2) and related system calls.
|
||||
setattr: called by the VFS to set attributes for a file. This method
|
||||
is called by chmod(2) and related system calls.
|
||||
|
||||
getattr: called by the VFS to get attributes of a file. This function is
|
||||
called by stat(2) and related system calls.
|
||||
getattr: called by the VFS to get attributes of a file. This method
|
||||
is called by stat(2) and related system calls.
|
||||
|
||||
setxattr: called by the VFS to set an extended attribute for a file.
|
||||
Extended attribute is a name:value pair associated with an inode. This
|
||||
function is called by setxattr(2) system call.
|
||||
Extended attribute is a name:value pair associated with an
|
||||
inode. This method is called by setxattr(2) system call.
|
||||
|
||||
getxattr: called by the VFS to retrieve the value of an extended attribute
|
||||
name. This function is called by getxattr(2) function call.
|
||||
getxattr: called by the VFS to retrieve the value of an extended
|
||||
attribute name. This method is called by getxattr(2) function
|
||||
call.
|
||||
|
||||
listxattr: called by the VFS to list all extended attributes for a given
|
||||
file. This function is called by listxattr(2) system call.
|
||||
listxattr: called by the VFS to list all extended attributes for a
|
||||
given file. This method is called by listxattr(2) system call.
|
||||
|
||||
removexattr: called by the VFS to remove an extended attribute from a file.
|
||||
This function is called by removexattr(2) system call.
|
||||
removexattr: called by the VFS to remove an extended attribute from
|
||||
a file. This method is called by removexattr(2) system call.
|
||||
|
||||
|
||||
The Address Space Object
|
||||
========================
|
||||
|
||||
The address space object is used to identify pages in the page cache.
|
||||
|
||||
|
||||
struct address_space_operations
|
||||
===============================
|
||||
-------------------------------
|
||||
|
||||
This describes how the VFS can manipulate mapping of a file to page cache in
|
||||
your filesystem. As of kernel 2.6.13, the following members are defined:
|
||||
|
@ -502,8 +512,14 @@ struct address_space_operations {
|
|||
it. An example implementation can be found in fs/ext2/xip.c.
|
||||
|
||||
|
||||
The File Object
|
||||
===============
|
||||
|
||||
A file object represents a file opened by a process.
|
||||
|
||||
|
||||
struct file_operations
|
||||
======================
|
||||
----------------------
|
||||
|
||||
This describes how the VFS can manipulate an open file. As of kernel
|
||||
2.6.13, the following members are defined:
|
||||
|
@ -661,7 +677,7 @@ of child dentries. Child dentries are basically like files in a
|
|||
directory.
|
||||
|
||||
|
||||
Directory Entry Cache APIs
|
||||
Directory Entry Cache API
|
||||
--------------------------
|
||||
|
||||
There are a number of functions defined which permit a filesystem to
|
||||
|
@ -705,178 +721,24 @@ manipulate dentries:
|
|||
and the dentry is returned. The caller must use d_put()
|
||||
to free the dentry when it finishes using it.
|
||||
|
||||
|
||||
RCU-based dcache locking model
|
||||
------------------------------
|
||||
|
||||
On many workloads, the most common operation on dcache is
|
||||
to look up a dentry, given a parent dentry and the name
|
||||
of the child. Typically, for every open(), stat() etc.,
|
||||
the dentry corresponding to the pathname will be looked
|
||||
up by walking the tree starting with the first component
|
||||
of the pathname and using that dentry along with the next
|
||||
component to look up the next level and so on. Since it
|
||||
is a frequent operation for workloads like multiuser
|
||||
environments and web servers, it is important to optimize
|
||||
this path.
|
||||
|
||||
Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus
|
||||
in every component during path look-up. Since 2.5.10 onwards,
|
||||
fast-walk algorithm changed this by holding the dcache_lock
|
||||
at the beginning and walking as many cached path component
|
||||
dentries as possible. This significantly decreases the number
|
||||
of acquisition of dcache_lock. However it also increases the
|
||||
lock hold time significantly and affects performance in large
|
||||
SMP machines. Since 2.5.62 kernel, dcache has been using
|
||||
a new locking model that uses RCU to make dcache look-up
|
||||
lock-free.
|
||||
|
||||
The current dcache locking model is not very different from the existing
|
||||
dcache locking model. Prior to 2.5.62 kernel, dcache_lock
|
||||
protected the hash chain, d_child, d_alias, d_lru lists as well
|
||||
as d_inode and several other things like mount look-up. RCU-based
|
||||
changes affect only the way the hash chain is protected. For everything
|
||||
else the dcache_lock must be taken for both traversing as well as
|
||||
updating. The hash chain updates too take the dcache_lock.
|
||||
The significant change is the way d_lookup traverses the hash chain,
|
||||
it doesn't acquire the dcache_lock for this and rely on RCU to
|
||||
ensure that the dentry has not been *freed*.
|
||||
For further information on dentry locking, please refer to the document
|
||||
Documentation/filesystems/dentry-locking.txt.
|
||||
|
||||
|
||||
Dcache locking details
|
||||
----------------------
|
||||
Resources
|
||||
=========
|
||||
|
||||
For many multi-user workloads, open() and stat() on files are
|
||||
very frequently occurring operations. Both involve walking
|
||||
of path names to find the dentry corresponding to the
|
||||
concerned file. In 2.4 kernel, dcache_lock was held
|
||||
during look-up of each path component. Contention and
|
||||
cache-line bouncing of this global lock caused significant
|
||||
scalability problems. With the introduction of RCU
|
||||
in Linux kernel, this was worked around by making
|
||||
the look-up of path components during path walking lock-free.
|
||||
(Note some of these resources are not up-to-date with the latest kernel
|
||||
version.)
|
||||
|
||||
Creating Linux virtual filesystems. 2002
|
||||
<http://lwn.net/Articles/13325/>
|
||||
|
||||
Safe lock-free look-up of dcache hash table
|
||||
===========================================
|
||||
The Linux Virtual File-system Layer by Neil Brown. 1999
|
||||
<http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/vfs.html>
|
||||
|
||||
Dcache is a complex data structure with the hash table entries
|
||||
also linked together in other lists. In 2.4 kernel, dcache_lock
|
||||
protected all the lists. We applied RCU only on hash chain
|
||||
walking. The rest of the lists are still protected by dcache_lock.
|
||||
Some of the important changes are :
|
||||
A tour of the Linux VFS by Michael K. Johnson. 1996
|
||||
<http://www.tldp.org/LDP/khg/HyperNews/get/fs/vfstour.html>
|
||||
|
||||
1. The deletion from hash chain is done using hlist_del_rcu() macro which
|
||||
doesn't initialize next pointer of the deleted dentry and this
|
||||
allows us to walk safely lock-free while a deletion is happening.
|
||||
|
||||
2. Insertion of a dentry into the hash table is done using
|
||||
hlist_add_head_rcu() which take care of ordering the writes -
|
||||
the writes to the dentry must be visible before the dentry
|
||||
is inserted. This works in conjunction with hlist_for_each_rcu()
|
||||
while walking the hash chain. The only requirement is that
|
||||
all initialization to the dentry must be done before hlist_add_head_rcu()
|
||||
since we don't have dcache_lock protection while traversing
|
||||
the hash chain. This isn't different from the existing code.
|
||||
|
||||
3. The dentry looked up without holding dcache_lock by cannot be
|
||||
returned for walking if it is unhashed. It then may have a NULL
|
||||
d_inode or other bogosity since RCU doesn't protect the other
|
||||
fields in the dentry. We therefore use a flag DCACHE_UNHASHED to
|
||||
indicate unhashed dentries and use this in conjunction with a
|
||||
per-dentry lock (d_lock). Once looked up without the dcache_lock,
|
||||
we acquire the per-dentry lock (d_lock) and check if the
|
||||
dentry is unhashed. If so, the look-up is failed. If not, the
|
||||
reference count of the dentry is increased and the dentry is returned.
|
||||
|
||||
4. Once a dentry is looked up, it must be ensured during the path
|
||||
walk for that component it doesn't go away. In pre-2.5.10 code,
|
||||
this was done holding a reference to the dentry. dcache_rcu does
|
||||
the same. In some sense, dcache_rcu path walking looks like
|
||||
the pre-2.5.10 version.
|
||||
|
||||
5. All dentry hash chain updates must take the dcache_lock as well as
|
||||
the per-dentry lock in that order. dput() does this to ensure
|
||||
that a dentry that has just been looked up in another CPU
|
||||
doesn't get deleted before dget() can be done on it.
|
||||
|
||||
6. There are several ways to do reference counting of RCU protected
|
||||
objects. One such example is in ipv4 route cache where
|
||||
deferred freeing (using call_rcu()) is done as soon as
|
||||
the reference count goes to zero. This cannot be done in
|
||||
the case of dentries because tearing down of dentries
|
||||
require blocking (dentry_iput()) which isn't supported from
|
||||
RCU callbacks. Instead, tearing down of dentries happen
|
||||
synchronously in dput(), but actual freeing happens later
|
||||
when RCU grace period is over. This allows safe lock-free
|
||||
walking of the hash chains, but a matched dentry may have
|
||||
been partially torn down. The checking of DCACHE_UNHASHED
|
||||
flag with d_lock held detects such dentries and prevents
|
||||
them from being returned from look-up.
|
||||
|
||||
|
||||
Maintaining POSIX rename semantics
|
||||
==================================
|
||||
|
||||
Since look-up of dentries is lock-free, it can race against
|
||||
a concurrent rename operation. For example, during rename
|
||||
of file A to B, look-up of either A or B must succeed.
|
||||
So, if look-up of B happens after A has been removed from the
|
||||
hash chain but not added to the new hash chain, it may fail.
|
||||
Also, a comparison while the name is being written concurrently
|
||||
by a rename may result in false positive matches violating
|
||||
rename semantics. Issues related to race with rename are
|
||||
handled as described below :
|
||||
|
||||
1. Look-up can be done in two ways - d_lookup() which is safe
|
||||
from simultaneous renames and __d_lookup() which is not.
|
||||
If __d_lookup() fails, it must be followed up by a d_lookup()
|
||||
to correctly determine whether a dentry is in the hash table
|
||||
or not. d_lookup() protects look-ups using a sequence
|
||||
lock (rename_lock).
|
||||
|
||||
2. The name associated with a dentry (d_name) may be changed if
|
||||
a rename is allowed to happen simultaneously. To avoid memcmp()
|
||||
in __d_lookup() go out of bounds due to a rename and false
|
||||
positive comparison, the name comparison is done while holding the
|
||||
per-dentry lock. This prevents concurrent renames during this
|
||||
operation.
|
||||
|
||||
3. Hash table walking during look-up may move to a different bucket as
|
||||
the current dentry is moved to a different bucket due to rename.
|
||||
But we use hlists in dcache hash table and they are null-terminated.
|
||||
So, even if a dentry moves to a different bucket, hash chain
|
||||
walk will terminate. [with a list_head list, it may not since
|
||||
termination is when the list_head in the original bucket is reached].
|
||||
Since we redo the d_parent check and compare name while holding
|
||||
d_lock, lock-free look-up will not race against d_move().
|
||||
|
||||
4. There can be a theoretical race when a dentry keeps coming back
|
||||
to original bucket due to double moves. Due to this look-up may
|
||||
consider that it has never moved and can end up in a infinite loop.
|
||||
But this is not any worse that theoretical livelocks we already
|
||||
have in the kernel.
|
||||
|
||||
|
||||
Important guidelines for filesystem developers related to dcache_rcu
|
||||
====================================================================
|
||||
|
||||
1. Existing dcache interfaces (pre-2.5.62) exported to filesystem
|
||||
don't change. Only dcache internal implementation changes. However
|
||||
filesystems *must not* delete from the dentry hash chains directly
|
||||
using the list macros like allowed earlier. They must use dcache
|
||||
APIs like d_drop() or __d_drop() depending on the situation.
|
||||
|
||||
2. d_flags is now protected by a per-dentry lock (d_lock). All
|
||||
access to d_flags must be protected by it.
|
||||
|
||||
3. For a hashed dentry, checking of d_count needs to be protected
|
||||
by d_lock.
|
||||
|
||||
|
||||
Papers and other documentation on dcache locking
|
||||
================================================
|
||||
|
||||
1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
|
||||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
A small trail through the Linux kernel by Andries Brouwer. 2001
|
||||
<http://www.win.tue.nl/~aeb/linux/vfs/trail.html>
|
||||
|
|
|
@ -19,15 +19,43 @@ Mount Options
|
|||
|
||||
When mounting an XFS filesystem, the following options are accepted.
|
||||
|
||||
biosize=size
|
||||
Sets the preferred buffered I/O size (default size is 64K).
|
||||
"size" must be expressed as the logarithm (base2) of the
|
||||
desired I/O size.
|
||||
Valid values for this option are 14 through 16, inclusive
|
||||
(i.e. 16K, 32K, and 64K bytes). On machines with a 4K
|
||||
pagesize, 13 (8K bytes) is also a valid size.
|
||||
The preferred buffered I/O size can also be altered on an
|
||||
individual file basis using the ioctl(2) system call.
|
||||
allocsize=size
|
||||
Sets the buffered I/O end-of-file preallocation size when
|
||||
doing delayed allocation writeout (default size is 64KiB).
|
||||
Valid values for this option are page size (typically 4KiB)
|
||||
through to 1GiB, inclusive, in power-of-2 increments.
|
||||
|
||||
attr2/noattr2
|
||||
The options enable/disable (default is disabled for backward
|
||||
compatibility on-disk) an "opportunistic" improvement to be
|
||||
made in the way inline extended attributes are stored on-disk.
|
||||
When the new form is used for the first time (by setting or
|
||||
removing extended attributes) the on-disk superblock feature
|
||||
bit field will be updated to reflect this format being in use.
|
||||
|
||||
barrier
|
||||
Enables the use of block layer write barriers for writes into
|
||||
the journal and unwritten extent conversion. This allows for
|
||||
drive level write caching to be enabled, for devices that
|
||||
support write barriers.
|
||||
|
||||
dmapi
|
||||
Enable the DMAPI (Data Management API) event callouts.
|
||||
Use with the "mtpt" option.
|
||||
|
||||
grpid/bsdgroups and nogrpid/sysvgroups
|
||||
These options define what group ID a newly created file gets.
|
||||
When grpid is set, it takes the group ID of the directory in
|
||||
which it is created; otherwise (the default) it takes the fsgid
|
||||
of the current process, unless the directory has the setgid bit
|
||||
set, in which case it takes the gid from the parent directory,
|
||||
and also gets the setgid bit set if it is a directory itself.
|
||||
|
||||
ihashsize=value
|
||||
Sets the number of hash buckets available for hashing the
|
||||
in-memory inodes of the specified mount point. If a value
|
||||
of zero is used, the value selected by the default algorithm
|
||||
will be displayed in /proc/mounts.
|
||||
|
||||
ikeep/noikeep
|
||||
When inode clusters are emptied of inodes, keep them around
|
||||
|
@ -35,12 +63,31 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
and is still the default for now. Using the noikeep option,
|
||||
inode clusters are returned to the free space pool.
|
||||
|
||||
inode64
|
||||
Indicates that XFS is allowed to create inodes at any location
|
||||
in the filesystem, including those which will result in inode
|
||||
numbers occupying more than 32 bits of significance. This is
|
||||
provided for backwards compatibility, but causes problems for
|
||||
backup applications that cannot handle large inode numbers.
|
||||
|
||||
largeio/nolargeio
|
||||
If "nolargeio" is specified, the optimal I/O reported in
|
||||
st_blksize by stat(2) will be as small as possible to allow user
|
||||
applications to avoid inefficient read/modify/write I/O.
|
||||
If "largeio" specified, a filesystem that has a "swidth" specified
|
||||
will return the "swidth" value (in bytes) in st_blksize. If the
|
||||
filesystem does not have a "swidth" specified but does specify
|
||||
an "allocsize" then "allocsize" (in bytes) will be returned
|
||||
instead.
|
||||
If neither of these two options are specified, then filesystem
|
||||
will behave as if "nolargeio" was specified.
|
||||
|
||||
logbufs=value
|
||||
Set the number of in-memory log buffers. Valid numbers range
|
||||
from 2-8 inclusive.
|
||||
The default value is 8 buffers for filesystems with a
|
||||
blocksize of 64K, 4 buffers for filesystems with a blocksize
|
||||
of 32K, 3 buffers for filesystems with a blocksize of 16K
|
||||
blocksize of 64KiB, 4 buffers for filesystems with a blocksize
|
||||
of 32KiB, 3 buffers for filesystems with a blocksize of 16KiB
|
||||
and 2 buffers for all other configurations. Increasing the
|
||||
number of buffers may increase performance on some workloads
|
||||
at the cost of the memory used for the additional log buffers
|
||||
|
@ -49,10 +96,10 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
logbsize=value
|
||||
Set the size of each in-memory log buffer.
|
||||
Size may be specified in bytes, or in kilobytes with a "k" suffix.
|
||||
Valid sizes for version 1 and version 2 logs are 16384 (16k) and
|
||||
32768 (32k). Valid sizes for version 2 logs also include
|
||||
Valid sizes for version 1 and version 2 logs are 16384 (16k) and
|
||||
32768 (32k). Valid sizes for version 2 logs also include
|
||||
65536 (64k), 131072 (128k) and 262144 (256k).
|
||||
The default value for machines with more than 32MB of memory
|
||||
The default value for machines with more than 32MiB of memory
|
||||
is 32768, machines with less memory use 16384 by default.
|
||||
|
||||
logdev=device and rtdev=device
|
||||
|
@ -62,6 +109,11 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
optional, and the log section can be separate from the data
|
||||
section or contained within it.
|
||||
|
||||
mtpt=mountpoint
|
||||
Use with the "dmapi" option. The value specified here will be
|
||||
included in the DMAPI mount event, and should be the path of
|
||||
the actual mountpoint that is used.
|
||||
|
||||
noalign
|
||||
Data allocations will not be aligned at stripe unit boundaries.
|
||||
|
||||
|
@ -91,13 +143,17 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
O_SYNC writes can be lost if the system crashes.
|
||||
If timestamp updates are critical, use the osyncisosync option.
|
||||
|
||||
quota/usrquota/uqnoenforce
|
||||
uquota/usrquota/uqnoenforce/quota
|
||||
User disk quota accounting enabled, and limits (optionally)
|
||||
enforced.
|
||||
enforced. Refer to xfs_quota(8) for further details.
|
||||
|
||||
grpquota/gqnoenforce
|
||||
gquota/grpquota/gqnoenforce
|
||||
Group disk quota accounting enabled and limits (optionally)
|
||||
enforced.
|
||||
enforced. Refer to xfs_quota(8) for further details.
|
||||
|
||||
pquota/prjquota/pqnoenforce
|
||||
Project disk quota accounting enabled and limits (optionally)
|
||||
enforced. Refer to xfs_quota(8) for further details.
|
||||
|
||||
sunit=value and swidth=value
|
||||
Used to specify the stripe unit and width for a RAID device or
|
||||
|
@ -113,15 +169,21 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
The "swidth" option is required if the "sunit" option has been
|
||||
specified, and must be a multiple of the "sunit" value.
|
||||
|
||||
swalloc
|
||||
Data allocations will be rounded up to stripe width boundaries
|
||||
when the current end of file is being extended and the file
|
||||
size is larger than the stripe width size.
|
||||
|
||||
|
||||
sysctls
|
||||
=======
|
||||
|
||||
The following sysctls are available for the XFS filesystem:
|
||||
|
||||
fs.xfs.stats_clear (Min: 0 Default: 0 Max: 1)
|
||||
Setting this to "1" clears accumulated XFS statistics
|
||||
Setting this to "1" clears accumulated XFS statistics
|
||||
in /proc/fs/xfs/stat. It then immediately resets to "0".
|
||||
|
||||
|
||||
fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000)
|
||||
The interval at which the xfssyncd thread flushes metadata
|
||||
out to disk. This thread will flush log activity out, and
|
||||
|
@ -143,9 +205,9 @@ The following sysctls are available for the XFS filesystem:
|
|||
XFS_ERRLEVEL_HIGH: 5
|
||||
|
||||
fs.xfs.panic_mask (Min: 0 Default: 0 Max: 127)
|
||||
Causes certain error conditions to call BUG(). Value is a bitmask;
|
||||
Causes certain error conditions to call BUG(). Value is a bitmask;
|
||||
AND together the tags which represent errors which should cause panics:
|
||||
|
||||
|
||||
XFS_NO_PTAG 0
|
||||
XFS_PTAG_IFLUSH 0x00000001
|
||||
XFS_PTAG_LOGRES 0x00000002
|
||||
|
@ -155,7 +217,7 @@ The following sysctls are available for the XFS filesystem:
|
|||
XFS_PTAG_SHUTDOWN_IOERROR 0x00000020
|
||||
XFS_PTAG_SHUTDOWN_LOGERROR 0x00000040
|
||||
|
||||
This option is intended for debugging only.
|
||||
This option is intended for debugging only.
|
||||
|
||||
fs.xfs.irix_symlink_mode (Min: 0 Default: 0 Max: 1)
|
||||
Controls whether symlinks are created with mode 0777 (default)
|
||||
|
@ -164,25 +226,37 @@ The following sysctls are available for the XFS filesystem:
|
|||
fs.xfs.irix_sgid_inherit (Min: 0 Default: 0 Max: 1)
|
||||
Controls files created in SGID directories.
|
||||
If the group ID of the new file does not match the effective group
|
||||
ID or one of the supplementary group IDs of the parent dir, the
|
||||
ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
|
||||
ID or one of the supplementary group IDs of the parent dir, the
|
||||
ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
|
||||
is set.
|
||||
|
||||
fs.xfs.restrict_chown (Min: 0 Default: 1 Max: 1)
|
||||
Controls whether unprivileged users can use chown to "give away"
|
||||
a file to another user.
|
||||
|
||||
fs.xfs.inherit_sync (Min: 0 Default: 1 Max 1)
|
||||
Setting this to "1" will cause the "sync" flag set
|
||||
by the chattr(1) command on a directory to be
|
||||
fs.xfs.inherit_sync (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "sync" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.inherit_nodump (Min: 0 Default: 1 Max 1)
|
||||
Setting this to "1" will cause the "nodump" flag set
|
||||
by the chattr(1) command on a directory to be
|
||||
fs.xfs.inherit_nodump (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "nodump" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.inherit_noatime (Min: 0 Default: 1 Max 1)
|
||||
Setting this to "1" will cause the "noatime" flag set
|
||||
by the chattr(1) command on a directory to be
|
||||
fs.xfs.inherit_noatime (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "noatime" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.inherit_nosymlinks (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "nosymlinks" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.rotorstep (Min: 1 Default: 1 Max: 256)
|
||||
In "inode32" allocation mode, this option determines how many
|
||||
files the allocator attempts to allocate in the same allocation
|
||||
group before moving to the next allocation group. The intent
|
||||
is to control the rate at which the allocator moves between
|
||||
allocation groups when allocating extents for new files.
|
||||
|
|
|
@ -1,18 +1,21 @@
|
|||
High Precision Event Timer Driver for Linux
|
||||
|
||||
The High Precision Event Timer (HPET) hardware is the future replacement for the 8254 and Real
|
||||
Time Clock (RTC) periodic timer functionality. Each HPET can have up two 32 timers. It is possible
|
||||
to configure the first two timers as legacy replacements for 8254 and RTC periodic. A specification
|
||||
done by INTEL and Microsoft can be found at http://www.intel.com/labs/platcomp/hpet/hpetspec.htm.
|
||||
The High Precision Event Timer (HPET) hardware is the future replacement
|
||||
for the 8254 and Real Time Clock (RTC) periodic timer functionality.
|
||||
Each HPET can have up two 32 timers. It is possible to configure the
|
||||
first two timers as legacy replacements for 8254 and RTC periodic timers.
|
||||
A specification done by Intel and Microsoft can be found at
|
||||
<http://www.intel.com/hardwaredesign/hpetspec.htm>.
|
||||
|
||||
The driver supports detection of HPET driver allocation and initialization of the HPET before the
|
||||
driver module_init routine is called. This enables platform code which uses timer 0 or 1 as the
|
||||
main timer to intercept HPET initialization. An example of this initialization can be found in
|
||||
The driver supports detection of HPET driver allocation and initialization
|
||||
of the HPET before the driver module_init routine is called. This enables
|
||||
platform code which uses timer 0 or 1 as the main timer to intercept HPET
|
||||
initialization. An example of this initialization can be found in
|
||||
arch/i386/kernel/time_hpet.c.
|
||||
|
||||
The driver provides two APIs which are very similar to the API found in the rtc.c driver.
|
||||
There is a user space API and a kernel space API. An example user space program is provided
|
||||
below.
|
||||
The driver provides two APIs which are very similar to the API found in
|
||||
the rtc.c driver. There is a user space API and a kernel space API.
|
||||
An example user space program is provided below.
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
|
@ -290,9 +293,8 @@ The kernel API has three interfaces exported from the driver:
|
|||
hpet_unregister(struct hpet_task *tp)
|
||||
hpet_control(struct hpet_task *tp, unsigned int cmd, unsigned long arg)
|
||||
|
||||
The kernel module using this interface fills in the ht_func and ht_data members of the
|
||||
hpet_task structure before calling hpet_register. hpet_control simply vectors to the hpet_ioctl
|
||||
routine and has the same commands and respective arguments as the user API. hpet_unregister
|
||||
The kernel module using this interface fills in the ht_func and ht_data
|
||||
members of the hpet_task structure before calling hpet_register.
|
||||
hpet_control simply vectors to the hpet_ioctl routine and has the same
|
||||
commands and respective arguments as the user API. hpet_unregister
|
||||
is used to terminate usage of the HPET timer reserved by hpet_register.
|
||||
|
||||
|
||||
|
|
|
@ -130,8 +130,6 @@ Code Seq# Include File Comments
|
|||
<mailto:zapman@interlan.net>
|
||||
'i' 00-3F linux/i2o.h
|
||||
'j' 00-3F linux/joystick.h
|
||||
'k' all asm-sparc/kbio.h
|
||||
asm-sparc64/kbio.h
|
||||
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||
<http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
|
|
|
@ -120,7 +120,7 @@ ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_li
|
|||
SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c
|
||||
STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h
|
||||
CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c
|
||||
SLAB_C_MAGIC 0x4f17a36d kmem_cache_s mm/slab.c
|
||||
SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
|
||||
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
|
||||
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
|
||||
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
|
||||
|
|
|
@ -116,3 +116,122 @@ and it's role in the array.
|
|||
|
||||
Once started with RUN_ARRAY, uninitialized spares can be added with
|
||||
HOT_ADD_DISK.
|
||||
|
||||
|
||||
|
||||
MD devices in sysfs
|
||||
-------------------
|
||||
md devices appear in sysfs (/sys) as regular block devices,
|
||||
e.g.
|
||||
/sys/block/md0
|
||||
|
||||
Each 'md' device will contain a subdirectory called 'md' which
|
||||
contains further md-specific information about the device.
|
||||
|
||||
All md devices contain:
|
||||
level
|
||||
a text file indicating the 'raid level'. This may be a standard
|
||||
numerical level prefixed by "RAID-" - e.g. "RAID-5", or some
|
||||
other name such as "linear" or "multipath".
|
||||
If no raid level has been set yet (array is still being
|
||||
assembled), this file will be empty.
|
||||
|
||||
raid_disks
|
||||
a text file with a simple number indicating the number of devices
|
||||
in a fully functional array. If this is not yet known, the file
|
||||
will be empty. If an array is being resized (not currently
|
||||
possible) this will contain the larger of the old and new sizes.
|
||||
|
||||
As component devices are added to an md array, they appear in the 'md'
|
||||
directory as new directories named
|
||||
dev-XXX
|
||||
where XXX is a name that the kernel knows for the device, e.g. hdb1.
|
||||
Each directory contains:
|
||||
|
||||
block
|
||||
a symlink to the block device in /sys/block, e.g.
|
||||
/sys/block/md0/md/dev-hdb1/block -> ../../../../block/hdb/hdb1
|
||||
|
||||
super
|
||||
A file containing an image of the superblock read from, or
|
||||
written to, that device.
|
||||
|
||||
state
|
||||
A file recording the current state of the device in the array
|
||||
which can be a comma separated list of
|
||||
faulty - device has been kicked from active use due to
|
||||
a detected fault
|
||||
in_sync - device is a fully in-sync member of the array
|
||||
spare - device is working, but not a full member.
|
||||
This includes spares that are in the process
|
||||
of being recoverred to
|
||||
This list make grow in future.
|
||||
|
||||
|
||||
An active md device will also contain and entry for each active device
|
||||
in the array. These are named
|
||||
|
||||
rdNN
|
||||
|
||||
where 'NN' is the possition in the array, starting from 0.
|
||||
So for a 3 drive array there will be rd0, rd1, rd2.
|
||||
These are symbolic links to the appropriate 'dev-XXX' entry.
|
||||
Thus, for example,
|
||||
cat /sys/block/md*/md/rd*/state
|
||||
will show 'in_sync' on every line.
|
||||
|
||||
|
||||
|
||||
Active md devices for levels that support data redundancy (1,4,5,6)
|
||||
also have
|
||||
|
||||
sync_action
|
||||
a text file that can be used to monitor and control the rebuild
|
||||
process. It contains one word which can be one of:
|
||||
resync - redundancy is being recalculated after unclean
|
||||
shutdown or creation
|
||||
recover - a hot spare is being built to replace a
|
||||
failed/missing device
|
||||
idle - nothing is happening
|
||||
check - A full check of redundancy was requested and is
|
||||
happening. This reads all block and checks
|
||||
them. A repair may also happen for some raid
|
||||
levels.
|
||||
repair - A full check and repair is happening. This is
|
||||
similar to 'resync', but was requested by the
|
||||
user, and the write-intent bitmap is NOT used to
|
||||
optimise the process.
|
||||
|
||||
This file is writable, and each of the strings that could be
|
||||
read are meaningful for writing.
|
||||
|
||||
'idle' will stop an active resync/recovery etc. There is no
|
||||
guarantee that another resync/recovery may not be automatically
|
||||
started again, though some event will be needed to trigger
|
||||
this.
|
||||
'resync' or 'recovery' can be used to restart the
|
||||
corresponding operation if it was stopped with 'idle'.
|
||||
'check' and 'repair' will start the appropriate process
|
||||
providing the current state is 'idle'.
|
||||
|
||||
mismatch_count
|
||||
When performing 'check' and 'repair', and possibly when
|
||||
performing 'resync', md will count the number of errors that are
|
||||
found. The count in 'mismatch_cnt' is the number of sectors
|
||||
that were re-written, or (for 'check') would have been
|
||||
re-written. As most raid levels work in units of pages rather
|
||||
than sectors, this my be larger than the number of actual errors
|
||||
by a factor of the number of sectors in a page.
|
||||
|
||||
Each active md device may also have attributes specific to the
|
||||
personality module that manages it.
|
||||
These are specific to the implementation of the module and could
|
||||
change substantially if the implementation changes.
|
||||
|
||||
These currently include
|
||||
|
||||
stripe_cache_size (currently raid5 only)
|
||||
number of entries in the stripe cache. This is writable, but
|
||||
there are upper and lower limits (32768, 16). Default is 128.
|
||||
strip_cache_active (currently raid5 only)
|
||||
number of active entries in the stripe cache
|
||||
|
|
|
@ -1,27 +1,82 @@
|
|||
|
||||
===========================
|
||||
Intel(R) PRO/Wireless 2100 Network Connection Driver for Linux
|
||||
Intel(R) PRO/Wireless 2100 Driver for Linux in support of:
|
||||
|
||||
Intel(R) PRO/Wireless 2100 Network Connection
|
||||
|
||||
Copyright (C) 2003-2005, Intel Corporation
|
||||
|
||||
README.ipw2100
|
||||
|
||||
March 14, 2005
|
||||
Version: 1.1.3
|
||||
Date : October 17, 2005
|
||||
|
||||
===========================
|
||||
Index
|
||||
---------------------------
|
||||
0. Introduction
|
||||
1. Release 1.1.0 Current Features
|
||||
2. Command Line Parameters
|
||||
3. Sysfs Helper Files
|
||||
4. Radio Kill Switch
|
||||
5. Dynamic Firmware
|
||||
6. Power Management
|
||||
7. Support
|
||||
8. License
|
||||
-----------------------------------------------
|
||||
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
|
||||
1. Introduction
|
||||
2. Release 1.1.3 Current Features
|
||||
3. Command Line Parameters
|
||||
4. Sysfs Helper Files
|
||||
5. Radio Kill Switch
|
||||
6. Dynamic Firmware
|
||||
7. Power Management
|
||||
8. Support
|
||||
9. License
|
||||
|
||||
|
||||
===========================
|
||||
0. Introduction
|
||||
------------ ----- ----- ---- --- -- -
|
||||
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
|
||||
-----------------------------------------------
|
||||
|
||||
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
|
||||
|
||||
Intel wireless LAN adapters are engineered, manufactured, tested, and
|
||||
quality checked to ensure that they meet all necessary local and
|
||||
governmental regulatory agency requirements for the regions that they
|
||||
are designated and/or marked to ship into. Since wireless LANs are
|
||||
generally unlicensed devices that share spectrum with radars,
|
||||
satellites, and other licensed and unlicensed devices, it is sometimes
|
||||
necessary to dynamically detect, avoid, and limit usage to avoid
|
||||
interference with these devices. In many instances Intel is required to
|
||||
provide test data to prove regional and local compliance to regional and
|
||||
governmental regulations before certification or approval to use the
|
||||
product is granted. Intel's wireless LAN's EEPROM, firmware, and
|
||||
software driver are designed to carefully control parameters that affect
|
||||
radio operation and to ensure electromagnetic compliance (EMC). These
|
||||
parameters include, without limitation, RF power, spectrum usage,
|
||||
channel scanning, and human exposure.
|
||||
|
||||
For these reasons Intel cannot permit any manipulation by third parties
|
||||
of the software provided in binary format with the wireless WLAN
|
||||
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
|
||||
patches, utilities, or code with the Intel wireless LAN adapters that
|
||||
have been manipulated by an unauthorized party (i.e., patches,
|
||||
utilities, or code (including open source code modifications) which have
|
||||
not been validated by Intel), (i) you will be solely responsible for
|
||||
ensuring the regulatory compliance of the products, (ii) Intel will bear
|
||||
no liability, under any theory of liability for any issues associated
|
||||
with the modified products, including without limitation, claims under
|
||||
the warranty and/or issues arising from regulatory non-compliance, and
|
||||
(iii) Intel will not provide or be required to assist in providing
|
||||
support to any third parties for such modified products.
|
||||
|
||||
Note: Many regulatory agencies consider Wireless LAN adapters to be
|
||||
modules, and accordingly, condition system-level regulatory approval
|
||||
upon receipt and review of test data documenting that the antennas and
|
||||
system configuration do not cause the EMC and radio operation to be
|
||||
non-compliant.
|
||||
|
||||
The drivers available for download from SourceForge are provided as a
|
||||
part of a development project. Conformance to local regulatory
|
||||
requirements is the responsibility of the individual developer. As
|
||||
such, if you are interested in deploying or shipping a driver as part of
|
||||
solution intended to be used for purposes other than development, please
|
||||
obtain a tested driver from Intel Customer Support at:
|
||||
|
||||
http://support.intel.com/support/notebook/sb/CS-006408.htm
|
||||
|
||||
|
||||
1. Introduction
|
||||
-----------------------------------------------
|
||||
|
||||
This document provides a brief overview of the features supported by the
|
||||
IPW2100 driver project. The main project website, where the latest
|
||||
|
@ -34,9 +89,8 @@ potential fixes and patches, as well as links to the development mailing list
|
|||
for the driver project.
|
||||
|
||||
|
||||
===========================
|
||||
1. Release 1.1.0 Current Supported Features
|
||||
---------------------------
|
||||
2. Release 1.1.3 Current Supported Features
|
||||
-----------------------------------------------
|
||||
- Managed (BSS) and Ad-Hoc (IBSS)
|
||||
- WEP (shared key and open)
|
||||
- Wireless Tools support
|
||||
|
@ -51,9 +105,8 @@ on the amount of validation and interoperability testing that has been
|
|||
performed on a given feature.
|
||||
|
||||
|
||||
===========================
|
||||
2. Command Line Parameters
|
||||
---------------------------
|
||||
3. Command Line Parameters
|
||||
-----------------------------------------------
|
||||
|
||||
If the driver is built as a module, the following optional parameters are used
|
||||
by entering them on the command line with the modprobe command using this
|
||||
|
@ -75,9 +128,9 @@ associate boolean associate=0 /* Do NOT auto associate */
|
|||
disable boolean disable=1 /* Do not power the HW */
|
||||
|
||||
|
||||
===========================
|
||||
3. Sysfs Helper Files
|
||||
4. Sysfs Helper Files
|
||||
---------------------------
|
||||
-----------------------------------------------
|
||||
|
||||
There are several ways to control the behavior of the driver. Many of the
|
||||
general capabilities are exposed through the Wireless Tools (iwconfig). There
|
||||
|
@ -120,9 +173,8 @@ For the device level files, see /sys/bus/pci/drivers/ipw2100:
|
|||
based RF kill from ON -> OFF -> ON, the radio will NOT come back on
|
||||
|
||||
|
||||
===========================
|
||||
4. Radio Kill Switch
|
||||
---------------------------
|
||||
5. Radio Kill Switch
|
||||
-----------------------------------------------
|
||||
Most laptops provide the ability for the user to physically disable the radio.
|
||||
Some vendors have implemented this as a physical switch that requires no
|
||||
software to turn the radio off and on. On other laptops, however, the switch
|
||||
|
@ -134,9 +186,8 @@ See the Sysfs helper file 'rf_kill' for determining the state of the RF switch
|
|||
on your system.
|
||||
|
||||
|
||||
===========================
|
||||
5. Dynamic Firmware
|
||||
---------------------------
|
||||
6. Dynamic Firmware
|
||||
-----------------------------------------------
|
||||
As the firmware is licensed under a restricted use license, it can not be
|
||||
included within the kernel sources. To enable the IPW2100 you will need a
|
||||
firmware image to load into the wireless NIC's processors.
|
||||
|
@ -146,9 +197,8 @@ You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
|
|||
See INSTALL for instructions on installing the firmware.
|
||||
|
||||
|
||||
===========================
|
||||
6. Power Management
|
||||
---------------------------
|
||||
7. Power Management
|
||||
-----------------------------------------------
|
||||
The IPW2100 supports the configuration of the Power Save Protocol
|
||||
through a private wireless extension interface. The IPW2100 supports
|
||||
the following different modes:
|
||||
|
@ -200,9 +250,8 @@ xxxx/yyyy will be replaced with 'off' -- the level reported will be the active
|
|||
level if `iwconfig eth1 power on` is invoked.
|
||||
|
||||
|
||||
===========================
|
||||
7. Support
|
||||
---------------------------
|
||||
8. Support
|
||||
-----------------------------------------------
|
||||
|
||||
For general development information and support,
|
||||
go to:
|
||||
|
@ -218,9 +267,8 @@ For installation support on the ipw2100 1.1.0 driver on Linux kernels
|
|||
|
||||
http://supportmail.intel.com
|
||||
|
||||
===========================
|
||||
8. License
|
||||
---------------------------
|
||||
9. License
|
||||
-----------------------------------------------
|
||||
|
||||
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
|
||||
|
||||
|
|
|
@ -1,33 +1,89 @@
|
|||
|
||||
Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
|
||||
|
||||
Intel(R) PRO/Wireless 2200BG Network Connection
|
||||
Intel(R) PRO/Wireless 2915ABG Network Connection
|
||||
Intel(R) PRO/Wireless 2200BG Network Connection
|
||||
Intel(R) PRO/Wireless 2915ABG Network Connection
|
||||
|
||||
Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
|
||||
PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
|
||||
both hardware adapters listed above. In this document the Intel(R)
|
||||
PRO/Wireless 2915ABG Driver for Linux will be used to reference the
|
||||
Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
|
||||
PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
|
||||
both hardware adapters listed above. In this document the Intel(R)
|
||||
PRO/Wireless 2915ABG Driver for Linux will be used to reference the
|
||||
unified driver.
|
||||
|
||||
Copyright (C) 2004-2005, Intel Corporation
|
||||
|
||||
README.ipw2200
|
||||
|
||||
Version: 1.0.0
|
||||
Date : January 31, 2005
|
||||
Version: 1.0.8
|
||||
Date : October 20, 2005
|
||||
|
||||
|
||||
Index
|
||||
-----------------------------------------------
|
||||
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
|
||||
1. Introduction
|
||||
1.1. Overview of features
|
||||
1.2. Module parameters
|
||||
1.3. Wireless Extension Private Methods
|
||||
1.4. Sysfs Helper Files
|
||||
2. About the Version Numbers
|
||||
3. Support
|
||||
4. License
|
||||
2. Ad-Hoc Networking
|
||||
3. Interacting with Wireless Tools
|
||||
3.1. iwconfig mode
|
||||
4. About the Version Numbers
|
||||
5. Firmware installation
|
||||
6. Support
|
||||
7. License
|
||||
|
||||
|
||||
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
|
||||
-----------------------------------------------
|
||||
|
||||
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
|
||||
|
||||
Intel wireless LAN adapters are engineered, manufactured, tested, and
|
||||
quality checked to ensure that they meet all necessary local and
|
||||
governmental regulatory agency requirements for the regions that they
|
||||
are designated and/or marked to ship into. Since wireless LANs are
|
||||
generally unlicensed devices that share spectrum with radars,
|
||||
satellites, and other licensed and unlicensed devices, it is sometimes
|
||||
necessary to dynamically detect, avoid, and limit usage to avoid
|
||||
interference with these devices. In many instances Intel is required to
|
||||
provide test data to prove regional and local compliance to regional and
|
||||
governmental regulations before certification or approval to use the
|
||||
product is granted. Intel's wireless LAN's EEPROM, firmware, and
|
||||
software driver are designed to carefully control parameters that affect
|
||||
radio operation and to ensure electromagnetic compliance (EMC). These
|
||||
parameters include, without limitation, RF power, spectrum usage,
|
||||
channel scanning, and human exposure.
|
||||
|
||||
For these reasons Intel cannot permit any manipulation by third parties
|
||||
of the software provided in binary format with the wireless WLAN
|
||||
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
|
||||
patches, utilities, or code with the Intel wireless LAN adapters that
|
||||
have been manipulated by an unauthorized party (i.e., patches,
|
||||
utilities, or code (including open source code modifications) which have
|
||||
not been validated by Intel), (i) you will be solely responsible for
|
||||
ensuring the regulatory compliance of the products, (ii) Intel will bear
|
||||
no liability, under any theory of liability for any issues associated
|
||||
with the modified products, including without limitation, claims under
|
||||
the warranty and/or issues arising from regulatory non-compliance, and
|
||||
(iii) Intel will not provide or be required to assist in providing
|
||||
support to any third parties for such modified products.
|
||||
|
||||
Note: Many regulatory agencies consider Wireless LAN adapters to be
|
||||
modules, and accordingly, condition system-level regulatory approval
|
||||
upon receipt and review of test data documenting that the antennas and
|
||||
system configuration do not cause the EMC and radio operation to be
|
||||
non-compliant.
|
||||
|
||||
The drivers available for download from SourceForge are provided as a
|
||||
part of a development project. Conformance to local regulatory
|
||||
requirements is the responsibility of the individual developer. As
|
||||
such, if you are interested in deploying or shipping a driver as part of
|
||||
solution intended to be used for purposes other than development, please
|
||||
obtain a tested driver from Intel Customer Support at:
|
||||
|
||||
http://support.intel.com/support/notebook/sb/CS-006408.htm
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
@ -45,7 +101,7 @@ file.
|
|||
|
||||
1.1. Overview of Features
|
||||
-----------------------------------------------
|
||||
The current release (1.0.0) supports the following features:
|
||||
The current release (1.0.8) supports the following features:
|
||||
|
||||
+ BSS mode (Infrastructure, Managed)
|
||||
+ IBSS mode (Ad-Hoc)
|
||||
|
@ -56,17 +112,27 @@ The current release (1.0.0) supports the following features:
|
|||
+ Full A rate support (2915 only)
|
||||
+ Transmit power control
|
||||
+ S state support (ACPI suspend/resume)
|
||||
|
||||
The following features are currently enabled, but not officially
|
||||
supported:
|
||||
|
||||
+ WPA
|
||||
+ long/short preamble support
|
||||
+ Monitor mode (aka RFMon)
|
||||
|
||||
The distinction between officially supported and enabled is a reflection
|
||||
on the amount of validation and interoperability testing that has been
|
||||
performed on a given feature.
|
||||
|
||||
|
||||
|
||||
1.2. Command Line Parameters
|
||||
-----------------------------------------------
|
||||
|
||||
Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
|
||||
2915ABG Driver for Linux allows certain configuration options to be
|
||||
provided as module parameters. The most common way to specify a module
|
||||
parameter is via the command line.
|
||||
Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
|
||||
2915ABG Driver for Linux allows configuration options to be provided
|
||||
as module parameters. The most common way to specify a module parameter
|
||||
is via the command line.
|
||||
|
||||
The general form is:
|
||||
|
||||
|
@ -96,14 +162,18 @@ Where the supported parameter are:
|
|||
|
||||
debug
|
||||
If using a debug build, this is used to control the amount of debug
|
||||
info is logged. See the 'dval' and 'load' script for more info on
|
||||
how to use this (the dval and load scripts are provided as part
|
||||
info is logged. See the 'dvals' and 'load' script for more info on
|
||||
how to use this (the dvals and load scripts are provided as part
|
||||
of the ipw2200 development snapshot releases available from the
|
||||
SourceForge project at http://ipw2200.sf.net)
|
||||
|
||||
led
|
||||
Can be used to turn on experimental LED code.
|
||||
0 = Off, 1 = On. Default is 0.
|
||||
|
||||
mode
|
||||
Can be used to set the default mode of the adapter.
|
||||
0 = Managed, 1 = Ad-Hoc
|
||||
0 = Managed, 1 = Ad-Hoc, 2 = Monitor
|
||||
|
||||
|
||||
1.3. Wireless Extension Private Methods
|
||||
|
@ -164,8 +234,8 @@ The supported private methods are:
|
|||
-----------------------------------------------
|
||||
|
||||
The Linux kernel provides a pseudo file system that can be used to
|
||||
access various components of the operating system. The Intel(R)
|
||||
PRO/Wireless 2915ABG Driver for Linux exposes several configuration
|
||||
access various components of the operating system. The Intel(R)
|
||||
PRO/Wireless 2915ABG Driver for Linux exposes several configuration
|
||||
parameters through this mechanism.
|
||||
|
||||
An entry in the sysfs can support reading and/or writing. You can
|
||||
|
@ -184,13 +254,13 @@ You can set the debug level via:
|
|||
|
||||
Where $VALUE would be a number in the case of this sysfs entry. The
|
||||
input to sysfs files does not have to be a number. For example, the
|
||||
firmware loader used by hotplug utilizes sysfs entries for transferring
|
||||
firmware loader used by hotplug utilizes sysfs entries for transfering
|
||||
the firmware image from user space into the driver.
|
||||
|
||||
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
|
||||
at two levels -- driver level, which apply to all instances of the
|
||||
driver (in the event that there are more than one device installed) and
|
||||
device level, which applies only to the single specific instance.
|
||||
at two levels -- driver level, which apply to all instances of the driver
|
||||
(in the event that there are more than one device installed) and device
|
||||
level, which applies only to the single specific instance.
|
||||
|
||||
|
||||
1.4.1 Driver Level Sysfs Helper Files
|
||||
|
@ -203,6 +273,7 @@ For the driver level files, look in /sys/bus/pci/drivers/ipw2200/
|
|||
This controls the same global as the 'debug' module parameter
|
||||
|
||||
|
||||
|
||||
1.4.2 Device Level Sysfs Helper Files
|
||||
-----------------------------------------------
|
||||
|
||||
|
@ -213,7 +284,7 @@ For the device level files, look in
|
|||
For example:
|
||||
/sys/bus/pci/drivers/ipw2200/0000:02:01.0
|
||||
|
||||
For the device level files, see /sys/bus/pci/[drivers/ipw2200:
|
||||
For the device level files, see /sys/bus/pci/drivers/ipw2200:
|
||||
|
||||
rf_kill
|
||||
read -
|
||||
|
@ -231,8 +302,59 @@ For the device level files, see /sys/bus/pci/[drivers/ipw2200:
|
|||
ucode
|
||||
read-only access to the ucode version number
|
||||
|
||||
led
|
||||
read -
|
||||
0 = LED code disabled
|
||||
1 = LED code enabled
|
||||
write -
|
||||
0 = Disable LED code
|
||||
1 = Enable LED code
|
||||
|
||||
2. About the Version Numbers
|
||||
NOTE: The LED code has been reported to hang some systems when
|
||||
running ifconfig and is therefore disabled by default.
|
||||
|
||||
|
||||
2. Ad-Hoc Networking
|
||||
-----------------------------------------------
|
||||
|
||||
When using a device in an Ad-Hoc network, it is useful to understand the
|
||||
sequence and requirements for the driver to be able to create, join, or
|
||||
merge networks.
|
||||
|
||||
The following attempts to provide enough information so that you can
|
||||
have a consistent experience while using the driver as a member of an
|
||||
Ad-Hoc network.
|
||||
|
||||
2.1. Joining an Ad-Hoc Network
|
||||
-----------------------------------------------
|
||||
|
||||
The easiest way to get onto an Ad-Hoc network is to join one that
|
||||
already exists.
|
||||
|
||||
2.2. Creating an Ad-Hoc Network
|
||||
-----------------------------------------------
|
||||
|
||||
An Ad-Hoc networks is created using the syntax of the Wireless tool.
|
||||
|
||||
For Example:
|
||||
iwconfig eth1 mode ad-hoc essid testing channel 2
|
||||
|
||||
2.3. Merging Ad-Hoc Networks
|
||||
-----------------------------------------------
|
||||
|
||||
|
||||
3. Interaction with Wireless Tools
|
||||
-----------------------------------------------
|
||||
|
||||
3.1 iwconfig mode
|
||||
-----------------------------------------------
|
||||
|
||||
When configuring the mode of the adapter, all run-time configured parameters
|
||||
are reset to the value used when the module was loaded. This includes
|
||||
channels, rates, ESSID, etc.
|
||||
|
||||
|
||||
4. About the Version Numbers
|
||||
-----------------------------------------------
|
||||
|
||||
Due to the nature of open source development projects, there are
|
||||
|
@ -259,12 +381,23 @@ available as quickly as possible, unknown anomalies should be expected.
|
|||
The major version number will be incremented when significant changes
|
||||
are made to the driver. Currently, there are no major changes planned.
|
||||
|
||||
5. Firmware installation
|
||||
----------------------------------------------
|
||||
|
||||
3. Support
|
||||
The driver requires a firmware image, download it and extract the
|
||||
files under /lib/firmware (or wherever your hotplug's firmware.agent
|
||||
will look for firmware files)
|
||||
|
||||
The firmware can be downloaded from the following URL:
|
||||
|
||||
http://ipw2200.sf.net/
|
||||
|
||||
|
||||
6. Support
|
||||
-----------------------------------------------
|
||||
|
||||
For installation support of the 1.0.0 version, you can contact
|
||||
http://supportmail.intel.com, or you can use the open source project
|
||||
For direct support of the 1.0.0 version, you can contact
|
||||
http://supportmail.intel.com, or you can use the open source project
|
||||
support.
|
||||
|
||||
For general information and support, go to:
|
||||
|
@ -272,7 +405,7 @@ For general information and support, go to:
|
|||
http://ipw2200.sf.net/
|
||||
|
||||
|
||||
4. License
|
||||
7. License
|
||||
-----------------------------------------------
|
||||
|
||||
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
|
||||
|
@ -297,4 +430,3 @@ For general information and support, go to:
|
|||
James P. Ketrenos <ipw2100-admin@linux.intel.com>
|
||||
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
|
||||
|
||||
|
||||
|
|
|
@ -176,8 +176,6 @@ information (_most_ of which _is_ _essential_) includes:
|
|||
- Which client caused the problem ?
|
||||
- How much data was being transferred ?
|
||||
- Was the network congested ?
|
||||
- If there was a kernel panic, please run the output through ksymoops
|
||||
before sending it to me, otherwise its _useless_.
|
||||
- How can the problem be reproduced ?
|
||||
- Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of
|
||||
tcpdump don't understand how to dump DECnet properly, so including
|
||||
|
|
|
@ -1,48 +1,153 @@
|
|||
S2IO Technologies XFrame 10 Gig adapter.
|
||||
-------------------------------------------
|
||||
Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver.
|
||||
|
||||
I. Module loadable parameters.
|
||||
When loaded as a module, the driver provides a host of Module loadable
|
||||
parameters, so the device can be tuned as per the users needs.
|
||||
A list of the Module params is given below.
|
||||
(i) ring_num: This can be used to program the number of
|
||||
receive rings used in the driver.
|
||||
(ii) ring_len: This defines the number of descriptors each ring
|
||||
can have. There can be a maximum of 8 rings.
|
||||
(iii) frame_len: This is an array of size 8. Using this we can
|
||||
set the maximum size of the received frame that can
|
||||
be steered into the corrsponding receive ring.
|
||||
(iv) fifo_num: This defines the number of Tx FIFOs thats used in
|
||||
the driver.
|
||||
(v) fifo_len: Each element defines the number of
|
||||
Tx descriptors that can be associated with each
|
||||
corresponding FIFO. There are a maximum of 8 FIFOs.
|
||||
(vi) tx_prio: This is a bool, if module is loaded with a non-zero
|
||||
value for tx_prio multi FIFO scheme is activated.
|
||||
(vii) rx_prio: This is a bool, if module is loaded with a non-zero
|
||||
value for tx_prio multi RING scheme is activated.
|
||||
(viii) latency_timer: The value given against this param will be
|
||||
loaded into the latency timer register in PCI Config
|
||||
space, else the register is left with its reset value.
|
||||
Contents
|
||||
=======
|
||||
- 1. Introduction
|
||||
- 2. Identifying the adapter/interface
|
||||
- 3. Features supported
|
||||
- 4. Command line parameters
|
||||
- 5. Performance suggestions
|
||||
- 6. Available Downloads
|
||||
|
||||
II. Performance tuning.
|
||||
By changing a few sysctl parameters.
|
||||
Copy the following lines into a file and run the following command,
|
||||
"sysctl -p <file_name>"
|
||||
### IPV4 specific settings
|
||||
net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use
|
||||
net.ipv4.tcp_sack = 0 # turn SACK support off, default on
|
||||
# on systems with a VERY fast bus -> memory interface this is the big gainer
|
||||
net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760
|
||||
net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072
|
||||
net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768
|
||||
|
||||
### CORE settings (mostly for socket and UDP effect)
|
||||
net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071
|
||||
net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071
|
||||
net.core.rmem_default = 524287 # default receive socket buffer size, default 65535
|
||||
net.core.wmem_default = 524287 # default send socket buffer size, default 65535
|
||||
net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240
|
||||
net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300
|
||||
---End of performance tuning file---
|
||||
|
||||
1. Introduction:
|
||||
This Linux driver supports Neterion's Xframe I PCI-X 1.0 and
|
||||
Xframe II PCI-X 2.0 adapters. It supports several features
|
||||
such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on.
|
||||
See below for complete list of features.
|
||||
All features are supported for both IPv4 and IPv6.
|
||||
|
||||
2. Identifying the adapter/interface:
|
||||
a. Insert the adapter(s) in your system.
|
||||
b. Build and load driver
|
||||
# insmod s2io.ko
|
||||
c. View log messages
|
||||
# dmesg | tail -40
|
||||
You will see messages similar to:
|
||||
eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA
|
||||
eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA
|
||||
eth4: Device is on 64 bit 133MHz PCIX(M1) bus
|
||||
|
||||
The above messages identify the adapter type(Xframe I/II), adapter revision,
|
||||
driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X).
|
||||
In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed
|
||||
as well.
|
||||
|
||||
To associate an interface with a physical adapter use "ethtool -p <ethX>".
|
||||
The corresponding adapter's LED will blink multiple times.
|
||||
|
||||
3. Features supported:
|
||||
a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes,
|
||||
modifiable using ifconfig command.
|
||||
|
||||
b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit
|
||||
and receive, TSO.
|
||||
|
||||
c. Multi-buffer receive mode. Scattering of packet across multiple
|
||||
buffers. Currently driver supports 2-buffer mode which yields
|
||||
significant performance improvement on certain platforms(SGI Altix,
|
||||
IBM xSeries).
|
||||
|
||||
d. MSI/MSI-X. Can be enabled on platforms which support this feature
|
||||
(IA64, Xeon) resulting in noticeable performance improvement(upto 7%
|
||||
on certain platforms).
|
||||
|
||||
e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt
|
||||
moderation.
|
||||
|
||||
f. Statistics. Comprehensive MAC-level and software statistics displayed
|
||||
using "ethtool -S" option.
|
||||
|
||||
g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings,
|
||||
with multiple steering options.
|
||||
|
||||
4. Command line parameters
|
||||
a. tx_fifo_num
|
||||
Number of transmit queues
|
||||
Valid range: 1-8
|
||||
Default: 1
|
||||
|
||||
b. rx_ring_num
|
||||
Number of receive rings
|
||||
Valid range: 1-8
|
||||
Default: 1
|
||||
|
||||
c. tx_fifo_len
|
||||
Size of each transmit queue
|
||||
Valid range: Total length of all queues should not exceed 8192
|
||||
Default: 4096
|
||||
|
||||
d. rx_ring_sz
|
||||
Size of each receive ring(in 4K blocks)
|
||||
Valid range: Limited by memory on system
|
||||
Default: 30
|
||||
|
||||
e. intr_type
|
||||
Specifies interrupt type. Possible values 1(INTA), 2(MSI), 3(MSI-X)
|
||||
Valid range: 1-3
|
||||
Default: 1
|
||||
|
||||
5. Performance suggestions
|
||||
General:
|
||||
a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration)
|
||||
b. Set TCP windows size to optimal value.
|
||||
For instance, for MTU=1500 a value of 210K has been observed to result in
|
||||
good performance.
|
||||
# sysctl -w net.ipv4.tcp_rmem="210000 210000 210000"
|
||||
# sysctl -w net.ipv4.tcp_wmem="210000 210000 210000"
|
||||
For MTU=9000, TCP window size of 10 MB is recommended.
|
||||
# sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
|
||||
# sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
|
||||
|
||||
Transmit performance:
|
||||
a. By default, the driver respects BIOS settings for PCI bus parameters.
|
||||
However, you may want to experiment with PCI bus parameters
|
||||
max-split-transactions(MOST) and MMRBC (use setpci command).
|
||||
A MOST value of 2 has been found optimal for Opterons and 3 for Itanium.
|
||||
It could be different for your hardware.
|
||||
Set MMRBC to 4K**.
|
||||
|
||||
For example you can set
|
||||
For opteron
|
||||
#setpci -d 17d5:* 62=1d
|
||||
For Itanium
|
||||
#setpci -d 17d5:* 62=3d
|
||||
|
||||
For detailed description of the PCI registers, please see Xframe User Guide.
|
||||
|
||||
b. Ensure Transmit Checksum offload is enabled. Use ethtool to set/verify this
|
||||
parameter.
|
||||
c. Turn on TSO(using "ethtool -K")
|
||||
# ethtool -K <ethX> tso on
|
||||
|
||||
Receive performance:
|
||||
a. By default, the driver respects BIOS settings for PCI bus parameters.
|
||||
However, you may want to set PCI latency timer to 248.
|
||||
#setpci -d 17d5:* LATENCY_TIMER=f8
|
||||
For detailed description of the PCI registers, please see Xframe User Guide.
|
||||
b. Use 2-buffer mode. This results in large performance boost on
|
||||
on certain platforms(eg. SGI Altix, IBM xSeries).
|
||||
c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to
|
||||
set/verify this option.
|
||||
d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network
|
||||
device support ---> Ethernet (10000 Mbit) ---> S2IO 10Gbe Xframe NIC) to
|
||||
bring down CPU utilization.
|
||||
|
||||
** For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are
|
||||
recommended as safe parameters.
|
||||
For more information, please review the AMD8131 errata at
|
||||
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26310.pdf
|
||||
|
||||
6. Available Downloads
|
||||
Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up
|
||||
to date, also the latest "s2io" code (including support for 2.4 kernels) is
|
||||
available via "Support" link on the Neterion site: http://www.neterion.com.
|
||||
|
||||
For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com,
|
||||
user: linuxdocs password: HALdocs
|
||||
|
||||
7. Support
|
||||
For further support please contact either your 10GbE Xframe NIC vendor (IBM,
|
||||
HP, SGI etc.) or click on the "Support" link on the Neterion site:
|
||||
http://www.neterion.com.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format
|
||||
(from dmesg, etc). Ignore any references in this or other docs to "decoding
|
||||
the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that
|
||||
the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that
|
||||
has been run through ksymoops, people will just tell you to repost it.
|
||||
|
||||
Quick Summary
|
||||
|
|
|
@ -11,9 +11,9 @@ boot video card. (Kernel usually does not even contain video card
|
|||
driver -- vesafb and vgacon are widely used).
|
||||
|
||||
This is not problem for swsusp, because during swsusp resume, BIOS is
|
||||
run normally so video card is normally initialized. S3 has absolutely
|
||||
no chance of working with SMP/HT. Be sure it to turn it off before
|
||||
testing (swsusp should work ok, OTOH).
|
||||
run normally so video card is normally initialized. It should not be
|
||||
problem for S1 standby, because hardware should retain its state over
|
||||
that.
|
||||
|
||||
There are a few types of systems where video works after S3 resume:
|
||||
|
||||
|
@ -64,7 +64,7 @@ your video card (good luck getting docs :-(). Maybe suspending from X
|
|||
(proper X, knowing your hardware, not XF68_FBcon) might have better
|
||||
chance of working.
|
||||
|
||||
Table of known working systems:
|
||||
Table of known working notebooks:
|
||||
|
||||
Model hack (or "how to do it")
|
||||
------------------------------------------------------------------------------
|
||||
|
@ -73,7 +73,7 @@ Acer TM 242FX vbetool (6)
|
|||
Acer TM C110 video_post (8)
|
||||
Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) or video_post (8)
|
||||
Acer TM 4052LCi s3_bios (2)
|
||||
Acer TM 636Lci s3_bios vga=normal (2)
|
||||
Acer TM 636Lci s3_bios,s3_mode (4)
|
||||
Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (5) gets text console back
|
||||
Acer TM 660 ??? (*)
|
||||
Acer TM 800 vga=normal, X patches, see webpage (5) or vbetool (6)
|
||||
|
@ -137,6 +137,13 @@ Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****)
|
|||
Toshiba M30 (2) xor X with nvidia driver using internal AGP
|
||||
Uniwill 244IIO ??? (*)
|
||||
|
||||
Known working desktop systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Mainboard Graphics card hack (or "how to do it")
|
||||
------------------------------------------------------------------------------
|
||||
Asus A7V8X nVidia RIVA TNT2 model 64 s3_bios,s3_mode (4)
|
||||
|
||||
|
||||
(*) from http://www.ubuntulinux.org/wiki/HoaryPMResults, not sure
|
||||
which options to use. If you know, please tell me.
|
||||
|
|
|
@ -871,7 +871,7 @@ by playing with the --adjust-vma parameter to objdump.
|
|||
|
||||
|
||||
|
||||
extern inline void spin_lock(spinlock_t *lp)
|
||||
static inline void spin_lock(spinlock_t *lp)
|
||||
{
|
||||
a0: 18 34 lr %r3,%r4
|
||||
a2: a7 3a 03 bc ahi %r3,956
|
||||
|
|
|
@ -8,11 +8,10 @@ All devices which can be addressed by means of ccws are called 'CCW devices' -
|
|||
even if they aren't actually driven by ccws.
|
||||
|
||||
All ccw devices are accessed via a subchannel, this is reflected in the
|
||||
structures under root/:
|
||||
structures under devices/:
|
||||
|
||||
root/
|
||||
- sys
|
||||
- legacy
|
||||
devices/
|
||||
- system/
|
||||
- css0/
|
||||
- 0.0.0000/0.0.0815/
|
||||
- 0.0.0001/0.0.4711/
|
||||
|
@ -36,7 +35,7 @@ availability: Can be 'good' or 'boxed'; 'no path' or 'no device' for
|
|||
|
||||
online: An interface to set the device online and offline.
|
||||
In the special case of the device being disconnected (see the
|
||||
notify function under 1.2), piping 0 to online will focibly delete
|
||||
notify function under 1.2), piping 0 to online will forcibly delete
|
||||
the device.
|
||||
|
||||
The device drivers can add entries to export per-device data and interfaces.
|
||||
|
@ -222,7 +221,7 @@ and are called 'chp0.<chpid>'. They have no driver and do not belong to any bus.
|
|||
Please note, that unlike /proc/chpids in 2.4, the channel path objects reflect
|
||||
only the logical state and not the physical state, since we cannot track the
|
||||
latter consistently due to lacking machine support (we don't need to be aware
|
||||
of anyway).
|
||||
of it anyway).
|
||||
|
||||
status - Can be 'online' or 'offline'.
|
||||
Piping 'on' or 'off' sets the chpid logically online/offline.
|
||||
|
@ -235,12 +234,16 @@ status - Can be 'online' or 'offline'.
|
|||
3. System devices
|
||||
-----------------
|
||||
|
||||
Note: cpus may yet be added here.
|
||||
|
||||
3.1 xpram
|
||||
---------
|
||||
|
||||
xpram shows up under sys/ as 'xpram'.
|
||||
xpram shows up under devices/system/ as 'xpram'.
|
||||
|
||||
3.2 cpus
|
||||
--------
|
||||
|
||||
For each cpu, a directory is created under devices/system/cpu/. Each cpu has an
|
||||
attribute 'online' which can be 0 or 1.
|
||||
|
||||
|
||||
4. Other devices
|
||||
|
|
|
@ -0,0 +1,89 @@
|
|||
CPU Scheduler implementation hints for architecture specific code
|
||||
|
||||
Nick Piggin, 2005
|
||||
|
||||
Context switch
|
||||
==============
|
||||
1. Runqueue locking
|
||||
By default, the switch_to arch function is called with the runqueue
|
||||
locked. This is usually not a problem unless switch_to may need to
|
||||
take the runqueue lock. This is usually due to a wake up operation in
|
||||
the context switch. See include/asm-ia64/system.h for an example.
|
||||
|
||||
To request the scheduler call switch_to with the runqueue unlocked,
|
||||
you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file
|
||||
(typically the one where switch_to is defined).
|
||||
|
||||
Unlocked context switches introduce only a very minor performance
|
||||
penalty to the core scheduler implementation in the CONFIG_SMP case.
|
||||
|
||||
2. Interrupt status
|
||||
By default, the switch_to arch function is called with interrupts
|
||||
disabled. Interrupts may be enabled over the call if it is likely to
|
||||
introduce a significant interrupt latency by adding the line
|
||||
`#define __ARCH_WANT_INTERRUPTS_ON_CTXSW` in the same place as for
|
||||
unlocked context switches. This define also implies
|
||||
`__ARCH_WANT_UNLOCKED_CTXSW`. See include/asm-arm/system.h for an
|
||||
example.
|
||||
|
||||
|
||||
CPU idle
|
||||
========
|
||||
Your cpu_idle routines need to obey the following rules:
|
||||
|
||||
1. Preempt should now disabled over idle routines. Should only
|
||||
be enabled to call schedule() then disabled again.
|
||||
|
||||
2. need_resched/TIF_NEED_RESCHED is only ever set, and will never
|
||||
be cleared until the running task has called schedule(). Idle
|
||||
threads need only ever query need_resched, and may never set or
|
||||
clear it.
|
||||
|
||||
3. When cpu_idle finds (need_resched() == 'true'), it should call
|
||||
schedule(). It should not call schedule() otherwise.
|
||||
|
||||
4. The only time interrupts need to be disabled when checking
|
||||
need_resched is if we are about to sleep the processor until
|
||||
the next interrupt (this doesn't provide any protection of
|
||||
need_resched, it prevents losing an interrupt).
|
||||
|
||||
4a. Common problem with this type of sleep appears to be:
|
||||
local_irq_disable();
|
||||
if (!need_resched()) {
|
||||
local_irq_enable();
|
||||
*** resched interrupt arrives here ***
|
||||
__asm__("sleep until next interrupt");
|
||||
}
|
||||
|
||||
5. TIF_POLLING_NRFLAG can be set by idle routines that do not
|
||||
need an interrupt to wake them up when need_resched goes high.
|
||||
In other words, they must be periodically polling need_resched,
|
||||
although it may be reasonable to do some background work or enter
|
||||
a low CPU priority.
|
||||
|
||||
5a. If TIF_POLLING_NRFLAG is set, and we do decide to enter
|
||||
an interrupt sleep, it needs to be cleared then a memory
|
||||
barrier issued (followed by a test of need_resched with
|
||||
interrupts disabled, as explained in 3).
|
||||
|
||||
arch/i386/kernel/process.c has examples of both polling and
|
||||
sleeping idle functions.
|
||||
|
||||
|
||||
Possible arch/ problems
|
||||
=======================
|
||||
|
||||
Possible arch problems I found (and either tried to fix or didn't):
|
||||
|
||||
h8300 - Is such sleeping racy vs interrupts? (See #4a).
|
||||
The H8/300 manual I found indicates yes, however disabling IRQs
|
||||
over the sleep mean only NMIs can wake it up, so can't fix easily
|
||||
without doing spin waiting.
|
||||
|
||||
ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
|
||||
|
||||
sh64 - Is sleeping racy vs interrupts? (See #4a)
|
||||
|
||||
sparc - IRQs on at this point(?), change local_irq_save to _disable.
|
||||
- TODO: needs secondary CPUs to disable preempt (See #1)
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
Copyright (c) 2003-2005 QLogic Corporation
|
||||
QLogic Linux Fibre Channel HBA Driver
|
||||
|
||||
This program includes a device driver for Linux 2.6 that may be
|
||||
distributed with QLogic hardware specific firmware binary file.
|
||||
You may modify and redistribute the device driver code under the
|
||||
GNU General Public License as published by the Free Software
|
||||
Foundation (version 2 or a later version).
|
||||
|
||||
You may redistribute the hardware specific firmware binary file
|
||||
under the following terms:
|
||||
|
||||
1. Redistribution of source code (only if applicable),
|
||||
must retain the above copyright notice, this list of
|
||||
conditions and the following disclaimer.
|
||||
|
||||
2. Redistribution in binary form must reproduce the above
|
||||
copyright notice, this list of conditions and the
|
||||
following disclaimer in the documentation and/or other
|
||||
materials provided with the distribution.
|
||||
|
||||
3. The name of QLogic Corporation may not be used to
|
||||
endorse or promote products derived from this software
|
||||
without specific prior written permission
|
||||
|
||||
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
|
||||
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
|
||||
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
||||
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
|
||||
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
|
||||
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
|
||||
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
|
||||
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
|
||||
COMBINATION WITH THIS PROGRAM.
|
File diff suppressed because it is too large
Load Diff
|
@ -167,7 +167,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
spdif - Support SPDIF I/O
|
||||
- Default: disabled
|
||||
|
||||
Module supports autoprobe and multiple chips (max 8).
|
||||
This module supports one chip and autoprobe.
|
||||
|
||||
The power-management is supported.
|
||||
|
||||
|
@ -206,7 +206,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
See "AC97 Quirk Option" section below.
|
||||
spdif_aclink - S/PDIF transfer over AC-link (default = 1)
|
||||
|
||||
This module supports up to 8 cards and autoprobe.
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
ATI IXP has two different methods to control SPDIF output. One is
|
||||
over AC-link and another is over the "direct" SPDIF output. The
|
||||
|
@ -218,7 +218,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
Module for ATI IXP 150/200/250 AC97 modem controllers.
|
||||
|
||||
Module supports up to 8 cards.
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
Note: The default index value of this module is -2, i.e. the first
|
||||
slot is excluded.
|
||||
|
@ -637,7 +637,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
model - force the model name
|
||||
position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
|
||||
|
||||
Module supports up to 8 cards.
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
Each codec may have a model table for different configurations.
|
||||
If your machine isn't listed there, the default (usually minimal)
|
||||
|
@ -663,6 +663,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
adjusted. Appearing only when compiled with
|
||||
$CONFIG_SND_DEBUG=y
|
||||
|
||||
ALC260
|
||||
hp HP machines
|
||||
fujitsu Fujitsu S7020
|
||||
|
||||
CMI9880
|
||||
minimal 3-jack in back
|
||||
min_fp 3-jack in back, 2-jack in front
|
||||
|
@ -811,7 +815,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
semaphores (e.g. on some ASUS laptops)
|
||||
(default off)
|
||||
|
||||
Module supports autoprobe and multiple bus-master chips (max 8).
|
||||
This module supports one chip and autoprobe.
|
||||
|
||||
Note: the latest driver supports auto-detection of chip clock.
|
||||
if you still encounter too fast playback, specify the clock
|
||||
|
@ -830,7 +834,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
ac97_clock - AC'97 codec clock base (0 = auto-detect)
|
||||
|
||||
This module supports up to 8 cards and autoprobe.
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
Note: The default index value of this module is -2, i.e. the first
|
||||
slot is excluded.
|
||||
|
@ -950,8 +954,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
use_cache - 0 or 1 (disabled by default)
|
||||
vaio_hack - alias buffer_top=0x25a800
|
||||
reset_workaround - enable AC97 RESET workaround for some laptops
|
||||
reset_workaround2 - enable extended AC97 RESET workaround for some
|
||||
other laptops
|
||||
|
||||
Module supports autoprobe and multiple chips (max 8).
|
||||
This module supports one chip and autoprobe.
|
||||
|
||||
The power-management is supported.
|
||||
|
||||
|
@ -980,6 +986,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
workaround is enabled automatically. For other laptops with a
|
||||
hard freeze, you can try reset_workaround=1 option.
|
||||
|
||||
Note: Dell Latitude CSx laptops have another problem regarding
|
||||
AC97 RESET. On these laptops, reset_workaround2 option is
|
||||
turned on as default. This option is worth to try if the
|
||||
previous reset_workaround option doesn't help.
|
||||
|
||||
Note: This driver is really crappy. It's a porting from the
|
||||
OSS driver, which is a result of black-magic reverse engineering.
|
||||
The detection of codec will fail if the driver is loaded *after*
|
||||
|
@ -1310,7 +1321,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
ac97_quirk - AC'97 workaround for strange hardware
|
||||
See "AC97 Quirk Option" section below.
|
||||
|
||||
Module supports autoprobe and multiple bus-master chips (max 8).
|
||||
This module supports one chip and autoprobe.
|
||||
|
||||
Note: on some SMP motherboards like MSI 694D the interrupts might
|
||||
not be generated properly. In such a case, please try to
|
||||
|
@ -1352,7 +1363,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
ac97_clock - AC'97 codec clock base (default 48000Hz)
|
||||
|
||||
Module supports up to 8 cards.
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
Note: The default index value of this module is -2, i.e. the first
|
||||
slot is excluded.
|
||||
|
|
|
@ -18,8 +18,8 @@
|
|||
</affiliation>
|
||||
</author>
|
||||
|
||||
<date>March 6, 2005</date>
|
||||
<edition>0.3.4</edition>
|
||||
<date>October 6, 2005</date>
|
||||
<edition>0.3.5</edition>
|
||||
|
||||
<abstract>
|
||||
<para>
|
||||
|
@ -30,7 +30,7 @@
|
|||
|
||||
<legalnotice>
|
||||
<para>
|
||||
Copyright (c) 2002-2004 Takashi Iwai <email>tiwai@suse.de</email>
|
||||
Copyright (c) 2002-2005 Takashi Iwai <email>tiwai@suse.de</email>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1433,25 +1433,10 @@
|
|||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
if (chip->res_port) {
|
||||
release_resource(chip->res_port);
|
||||
kfree_nocheck(chip->res_port);
|
||||
}
|
||||
release_and_free_resource(chip->res_port);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
As you can see, the resource pointer is also to be freed
|
||||
via <function>kfree_nocheck()</function> after
|
||||
<function>release_resource()</function> is called. You
|
||||
cannot use <function>kfree()</function> here, because on ALSA,
|
||||
<function>kfree()</function> may be a wrapper to its own
|
||||
allocator with the memory debugging. Since the resource pointer
|
||||
is allocated externally outside the ALSA, it must be released
|
||||
via the native
|
||||
<function>kfree()</function>.
|
||||
<function>kfree_nocheck()</function> is used for that; it calls
|
||||
the native <function>kfree()</function> without wrapper.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -2190,8 +2175,7 @@ struct _snd_pcm_runtime {
|
|||
unsigned int rate_den;
|
||||
|
||||
/* -- SW params -- */
|
||||
int tstamp_timespec; /* use timeval (0) or timespec (1) */
|
||||
snd_pcm_tstamp_t tstamp_mode; /* mmap timestamp is updated */
|
||||
struct timespec tstamp_mode; /* mmap timestamp is updated */
|
||||
unsigned int period_step;
|
||||
unsigned int sleep_min; /* min ticks to sleep */
|
||||
snd_pcm_uframes_t xfer_align; /* xfer size need to be a multiple */
|
||||
|
@ -3709,8 +3693,7 @@ struct _snd_pcm_runtime {
|
|||
<para>
|
||||
Here, the chip instance is retrieved via
|
||||
<function>snd_kcontrol_chip()</function> macro. This macro
|
||||
converts from kcontrol->private_data to the type defined by
|
||||
<type>chip_t</type>. The
|
||||
just accesses to kcontrol->private_data. The
|
||||
kcontrol->private_data field is
|
||||
given as the argument of <function>snd_ctl_new()</function>
|
||||
(see the later subsection
|
||||
|
@ -5998,32 +5981,23 @@ struct _snd_pcm_runtime {
|
|||
The first argument is the expression to evaluate, and the
|
||||
second argument is the action if it fails. When
|
||||
<constant>CONFIG_SND_DEBUG</constant>, is set, it will show an
|
||||
error message such as <computeroutput>BUG? (xxx) (called from
|
||||
yyy)</computeroutput>. When no debug flag is set, this is
|
||||
ignored.
|
||||
error message such as <computeroutput>BUG? (xxx)</computeroutput>
|
||||
together with stack trace.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="useful-functions-snd-runtime-check">
|
||||
<title><function>snd_runtime_check()</function></title>
|
||||
<para>
|
||||
This macro is quite similar with
|
||||
<function>snd_assert()</function>. Unlike
|
||||
<function>snd_assert()</function>, the expression is always
|
||||
evaluated regardless of
|
||||
<constant>CONFIG_SND_DEBUG</constant>. When
|
||||
<constant>CONFIG_SND_DEBUG</constant> is set, the macro will
|
||||
show a message like <computeroutput>ERROR (xx) (called from
|
||||
yyy)</computeroutput>.
|
||||
When no debug flag is set, this macro is ignored.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="useful-functions-snd-bug">
|
||||
<title><function>snd_BUG()</function></title>
|
||||
<para>
|
||||
It calls <function>snd_assert(0,)</function> -- that is, just
|
||||
prints the error message at the point. It's useful to show that
|
||||
a fatal error happens there.
|
||||
It shows <computeroutput>BUG?</computeroutput> message and
|
||||
stack trace as well as <function>snd_assert</function> at the point.
|
||||
It's useful to show that a fatal error happens there.
|
||||
</para>
|
||||
<para>
|
||||
When no debug flag is set, this macro is ignored.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
|
@ -41,9 +41,9 @@ sure that bitwise types don't get mixed up (little-endian vs big-endian
|
|||
vs cpu-endian vs whatever), and there the constant "0" really _is_
|
||||
special.
|
||||
|
||||
Modify top-level Makefile to say
|
||||
Use
|
||||
|
||||
CHECK = sparse -Wbitwise
|
||||
make C=[12] CF=-Wbitwise
|
||||
|
||||
or you don't get any checking at all.
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ V4L original API</a>
|
|||
</td><td>
|
||||
Obsoleted by V4L2 API
|
||||
</td></tr><tr><td>
|
||||
<A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L2_API.html>
|
||||
<A HREF=http://www.linuxtv.org/downloads/video4linux/API/V4L2_API>
|
||||
V4L2 API</a>
|
||||
</td><td>
|
||||
Should be used for new projects
|
||||
|
|
|
@ -1,137 +1,142 @@
|
|||
card=0 - *** UNKNOWN/GENERIC ***
|
||||
card=1 - MIRO PCTV
|
||||
card=2 - Hauppauge (bt848)
|
||||
card=3 - STB, Gateway P/N 6000699 (bt848)
|
||||
card=4 - Intel Create and Share PCI/ Smart Video Recorder III
|
||||
card=5 - Diamond DTV2000
|
||||
card=6 - AVerMedia TVPhone
|
||||
card=7 - MATRIX-Vision MV-Delta
|
||||
card=8 - Lifeview FlyVideo II (Bt848) LR26 / MAXI TV Video PCI2 LR26
|
||||
card=9 - IMS/IXmicro TurboTV
|
||||
card=10 - Hauppauge (bt878)
|
||||
card=11 - MIRO PCTV pro
|
||||
card=12 - ADS Technologies Channel Surfer TV (bt848)
|
||||
card=13 - AVerMedia TVCapture 98
|
||||
card=14 - Aimslab Video Highway Xtreme (VHX)
|
||||
card=15 - Zoltrix TV-Max
|
||||
card=16 - Prolink Pixelview PlayTV (bt878)
|
||||
card=17 - Leadtek WinView 601
|
||||
card=18 - AVEC Intercapture
|
||||
card=19 - Lifeview FlyVideo II EZ /FlyKit LR38 Bt848 (capture only)
|
||||
card=20 - CEI Raffles Card
|
||||
card=21 - Lifeview FlyVideo 98/ Lucky Star Image World ConferenceTV LR50
|
||||
card=22 - Askey CPH050/ Phoebe Tv Master + FM
|
||||
card=23 - Modular Technology MM201/MM202/MM205/MM210/MM215 PCTV, bt878
|
||||
card=24 - Askey CPH05X/06X (bt878) [many vendors]
|
||||
card=25 - Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar
|
||||
card=26 - Hauppauge WinCam newer (bt878)
|
||||
card=27 - Lifeview FlyVideo 98/ MAXI TV Video PCI2 LR50
|
||||
card=28 - Terratec TerraTV+ Version 1.1 (bt878)
|
||||
card=29 - Imagenation PXC200
|
||||
card=30 - Lifeview FlyVideo 98 LR50
|
||||
card=31 - Formac iProTV, Formac ProTV I (bt848)
|
||||
card=32 - Intel Create and Share PCI/ Smart Video Recorder III
|
||||
card=33 - Terratec TerraTValue Version Bt878
|
||||
card=34 - Leadtek WinFast 2000/ WinFast 2000 XP
|
||||
card=35 - Lifeview FlyVideo 98 LR50 / Chronos Video Shuttle II
|
||||
card=36 - Lifeview FlyVideo 98FM LR50 / Typhoon TView TV/FM Tuner
|
||||
card=37 - Prolink PixelView PlayTV pro
|
||||
card=38 - Askey CPH06X TView99
|
||||
card=39 - Pinnacle PCTV Studio/Rave
|
||||
card=40 - STB TV PCI FM, Gateway P/N 6000704 (bt878), 3Dfx VoodooTV 100
|
||||
card=41 - AVerMedia TVPhone 98
|
||||
card=42 - ProVideo PV951
|
||||
card=43 - Little OnAir TV
|
||||
card=44 - Sigma TVII-FM
|
||||
card=45 - MATRIX-Vision MV-Delta 2
|
||||
card=46 - Zoltrix Genie TV/FM
|
||||
card=47 - Terratec TV/Radio+
|
||||
card=48 - Askey CPH03x/ Dynalink Magic TView
|
||||
card=49 - IODATA GV-BCTV3/PCI
|
||||
card=50 - Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP
|
||||
card=51 - Eagle Wireless Capricorn2 (bt878A)
|
||||
card=52 - Pinnacle PCTV Studio Pro
|
||||
card=53 - Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS
|
||||
card=54 - Lifeview FlyVideo 2000 /FlyVideo A2/ Lifetec LT 9415 TV [LR90]
|
||||
card=55 - Askey CPH031/ BESTBUY Easy TV
|
||||
card=56 - Lifeview FlyVideo 98FM LR50
|
||||
card=57 - GrandTec 'Grand Video Capture' (Bt848)
|
||||
card=58 - Askey CPH060/ Phoebe TV Master Only (No FM)
|
||||
card=59 - Askey CPH03x TV Capturer
|
||||
card=60 - Modular Technology MM100PCTV
|
||||
card=61 - AG Electronics GMV1
|
||||
card=62 - Askey CPH061/ BESTBUY Easy TV (bt878)
|
||||
card=63 - ATI TV-Wonder
|
||||
card=64 - ATI TV-Wonder VE
|
||||
card=65 - Lifeview FlyVideo 2000S LR90
|
||||
card=66 - Terratec TValueRadio
|
||||
card=67 - IODATA GV-BCTV4/PCI
|
||||
card=68 - 3Dfx VoodooTV FM (Euro), VoodooTV 200 (USA)
|
||||
card=69 - Active Imaging AIMMS
|
||||
card=70 - Prolink Pixelview PV-BT878P+ (Rev.4C,8E)
|
||||
card=71 - Lifeview FlyVideo 98EZ (capture only) LR51
|
||||
card=72 - Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM)
|
||||
card=73 - Sensoray 311
|
||||
card=74 - RemoteVision MX (RV605)
|
||||
card=75 - Powercolor MTV878/ MTV878R/ MTV878F
|
||||
card=76 - Canopus WinDVR PCI (COMPAQ Presario 3524JP, 5112JP)
|
||||
card=77 - GrandTec Multi Capture Card (Bt878)
|
||||
card=78 - Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF
|
||||
card=79 - DSP Design TCVIDEO
|
||||
card=80 - Hauppauge WinTV PVR
|
||||
card=81 - IODATA GV-BCTV5/PCI
|
||||
card=82 - Osprey 100/150 (878)
|
||||
card=83 - Osprey 100/150 (848)
|
||||
card=84 - Osprey 101 (848)
|
||||
card=85 - Osprey 101/151
|
||||
card=86 - Osprey 101/151 w/ svid
|
||||
card=87 - Osprey 200/201/250/251
|
||||
card=88 - Osprey 200/250
|
||||
card=89 - Osprey 210/220
|
||||
card=90 - Osprey 500
|
||||
card=91 - Osprey 540
|
||||
card=92 - Osprey 2000
|
||||
card=93 - IDS Eagle
|
||||
card=94 - Pinnacle PCTV Sat
|
||||
card=95 - Formac ProTV II (bt878)
|
||||
card=96 - MachTV
|
||||
card=97 - Euresys Picolo
|
||||
card=98 - ProVideo PV150
|
||||
card=99 - AD-TVK503
|
||||
card=100 - Hercules Smart TV Stereo
|
||||
card=101 - Pace TV & Radio Card
|
||||
card=102 - IVC-200
|
||||
card=103 - Grand X-Guard / Trust 814PCI
|
||||
card=104 - Nebula Electronics DigiTV
|
||||
card=105 - ProVideo PV143
|
||||
card=106 - PHYTEC VD-009-X1 MiniDIN (bt878)
|
||||
card=107 - PHYTEC VD-009-X1 Combi (bt878)
|
||||
card=108 - PHYTEC VD-009 MiniDIN (bt878)
|
||||
card=109 - PHYTEC VD-009 Combi (bt878)
|
||||
card=110 - IVC-100
|
||||
card=111 - IVC-120G
|
||||
card=112 - pcHDTV HD-2000 TV
|
||||
card=113 - Twinhan DST + clones
|
||||
card=114 - Winfast VC100
|
||||
card=115 - Teppro TEV-560/InterVision IV-560
|
||||
card=116 - SIMUS GVC1100
|
||||
card=117 - NGS NGSTV+
|
||||
card=118 - LMLBT4
|
||||
card=119 - Tekram M205 PRO
|
||||
card=120 - Conceptronic CONTVFMi
|
||||
card=121 - Euresys Picolo Tetra
|
||||
card=122 - Spirit TV Tuner
|
||||
card=123 - AVerMedia AVerTV DVB-T 771
|
||||
card=124 - AverMedia AverTV DVB-T 761
|
||||
card=125 - MATRIX Vision Sigma-SQ
|
||||
card=126 - MATRIX Vision Sigma-SLC
|
||||
card=127 - APAC Viewcomp 878(AMAX)
|
||||
card=128 - DViCO FusionHDTV DVB-T Lite
|
||||
card=129 - V-Gear MyVCD
|
||||
card=130 - Super TV Tuner
|
||||
card=131 - Tibet Systems 'Progress DVR' CS16
|
||||
card=132 - Kodicom 4400R (master)
|
||||
card=133 - Kodicom 4400R (slave)
|
||||
card=134 - Adlink RTV24
|
||||
card=135 - DViCO FusionHDTV 5 Lite
|
||||
card=136 - Acorp Y878F
|
||||
0 -> *** UNKNOWN/GENERIC ***
|
||||
1 -> MIRO PCTV
|
||||
2 -> Hauppauge (bt848)
|
||||
3 -> STB, Gateway P/N 6000699 (bt848)
|
||||
4 -> Intel Create and Share PCI/ Smart Video Recorder III
|
||||
5 -> Diamond DTV2000
|
||||
6 -> AVerMedia TVPhone
|
||||
7 -> MATRIX-Vision MV-Delta
|
||||
8 -> Lifeview FlyVideo II (Bt848) LR26 / MAXI TV Video PCI2 LR26
|
||||
9 -> IMS/IXmicro TurboTV
|
||||
10 -> Hauppauge (bt878) [0070:13eb,0070:3900,2636:10b4]
|
||||
11 -> MIRO PCTV pro
|
||||
12 -> ADS Technologies Channel Surfer TV (bt848)
|
||||
13 -> AVerMedia TVCapture 98 [1461:0002,1461:0004,1461:0300]
|
||||
14 -> Aimslab Video Highway Xtreme (VHX)
|
||||
15 -> Zoltrix TV-Max [a1a0:a0fc]
|
||||
16 -> Prolink Pixelview PlayTV (bt878)
|
||||
17 -> Leadtek WinView 601
|
||||
18 -> AVEC Intercapture
|
||||
19 -> Lifeview FlyVideo II EZ /FlyKit LR38 Bt848 (capture only)
|
||||
20 -> CEI Raffles Card
|
||||
21 -> Lifeview FlyVideo 98/ Lucky Star Image World ConferenceTV LR50
|
||||
22 -> Askey CPH050/ Phoebe Tv Master + FM [14ff:3002]
|
||||
23 -> Modular Technology MM201/MM202/MM205/MM210/MM215 PCTV, bt878 [14c7:0101]
|
||||
24 -> Askey CPH05X/06X (bt878) [many vendors] [144f:3002,144f:3005,144f:5000,14ff:3000]
|
||||
25 -> Terratec TerraTV+ Version 1.0 (Bt848)/ Terra TValue Version 1.0/ Vobis TV-Boostar
|
||||
26 -> Hauppauge WinCam newer (bt878)
|
||||
27 -> Lifeview FlyVideo 98/ MAXI TV Video PCI2 LR50
|
||||
28 -> Terratec TerraTV+ Version 1.1 (bt878) [153b:1127,1852:1852]
|
||||
29 -> Imagenation PXC200 [1295:200a]
|
||||
30 -> Lifeview FlyVideo 98 LR50 [1f7f:1850]
|
||||
31 -> Formac iProTV, Formac ProTV I (bt848)
|
||||
32 -> Intel Create and Share PCI/ Smart Video Recorder III
|
||||
33 -> Terratec TerraTValue Version Bt878 [153b:1117,153b:1118,153b:1119,153b:111a,153b:1134,153b:5018]
|
||||
34 -> Leadtek WinFast 2000/ WinFast 2000 XP [107d:6606,107d:6609,6606:217d,f6ff:fff6]
|
||||
35 -> Lifeview FlyVideo 98 LR50 / Chronos Video Shuttle II [1851:1850,1851:a050]
|
||||
36 -> Lifeview FlyVideo 98FM LR50 / Typhoon TView TV/FM Tuner [1852:1852]
|
||||
37 -> Prolink PixelView PlayTV pro
|
||||
38 -> Askey CPH06X TView99 [144f:3000,144f:a005,a04f:a0fc]
|
||||
39 -> Pinnacle PCTV Studio/Rave [11bd:0012,bd11:1200,bd11:ff00,11bd:ff12]
|
||||
40 -> STB TV PCI FM, Gateway P/N 6000704 (bt878), 3Dfx VoodooTV 100 [10b4:2636,10b4:2645,121a:3060]
|
||||
41 -> AVerMedia TVPhone 98 [1461:0001,1461:0003]
|
||||
42 -> ProVideo PV951 [aa0c:146c]
|
||||
43 -> Little OnAir TV
|
||||
44 -> Sigma TVII-FM
|
||||
45 -> MATRIX-Vision MV-Delta 2
|
||||
46 -> Zoltrix Genie TV/FM [15b0:4000,15b0:400a,15b0:400d,15b0:4010,15b0:4016]
|
||||
47 -> Terratec TV/Radio+ [153b:1123]
|
||||
48 -> Askey CPH03x/ Dynalink Magic TView
|
||||
49 -> IODATA GV-BCTV3/PCI [10fc:4020]
|
||||
50 -> Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP
|
||||
51 -> Eagle Wireless Capricorn2 (bt878A)
|
||||
52 -> Pinnacle PCTV Studio Pro
|
||||
53 -> Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS
|
||||
54 -> Lifeview FlyVideo 2000 /FlyVideo A2/ Lifetec LT 9415 TV [LR90]
|
||||
55 -> Askey CPH031/ BESTBUY Easy TV
|
||||
56 -> Lifeview FlyVideo 98FM LR50 [a051:41a0]
|
||||
57 -> GrandTec 'Grand Video Capture' (Bt848) [4344:4142]
|
||||
58 -> Askey CPH060/ Phoebe TV Master Only (No FM)
|
||||
59 -> Askey CPH03x TV Capturer
|
||||
60 -> Modular Technology MM100PCTV
|
||||
61 -> AG Electronics GMV1 [15cb:0101]
|
||||
62 -> Askey CPH061/ BESTBUY Easy TV (bt878)
|
||||
63 -> ATI TV-Wonder [1002:0001]
|
||||
64 -> ATI TV-Wonder VE [1002:0003]
|
||||
65 -> Lifeview FlyVideo 2000S LR90
|
||||
66 -> Terratec TValueRadio [153b:1135,153b:ff3b]
|
||||
67 -> IODATA GV-BCTV4/PCI [10fc:4050]
|
||||
68 -> 3Dfx VoodooTV FM (Euro), VoodooTV 200 (USA) [121a:3000,10b4:2637]
|
||||
69 -> Active Imaging AIMMS
|
||||
70 -> Prolink Pixelview PV-BT878P+ (Rev.4C,8E)
|
||||
71 -> Lifeview FlyVideo 98EZ (capture only) LR51 [1851:1851]
|
||||
72 -> Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM) [1554:4011]
|
||||
73 -> Sensoray 311 [6000:0311]
|
||||
74 -> RemoteVision MX (RV605)
|
||||
75 -> Powercolor MTV878/ MTV878R/ MTV878F
|
||||
76 -> Canopus WinDVR PCI (COMPAQ Presario 3524JP, 5112JP) [0e11:0079]
|
||||
77 -> GrandTec Multi Capture Card (Bt878)
|
||||
78 -> Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [0a01:17de]
|
||||
79 -> DSP Design TCVIDEO
|
||||
80 -> Hauppauge WinTV PVR [0070:4500]
|
||||
81 -> IODATA GV-BCTV5/PCI [10fc:4070,10fc:d018]
|
||||
82 -> Osprey 100/150 (878) [0070:ff00]
|
||||
83 -> Osprey 100/150 (848)
|
||||
84 -> Osprey 101 (848)
|
||||
85 -> Osprey 101/151
|
||||
86 -> Osprey 101/151 w/ svid
|
||||
87 -> Osprey 200/201/250/251
|
||||
88 -> Osprey 200/250 [0070:ff01]
|
||||
89 -> Osprey 210/220
|
||||
90 -> Osprey 500 [0070:ff02]
|
||||
91 -> Osprey 540 [0070:ff04]
|
||||
92 -> Osprey 2000 [0070:ff03]
|
||||
93 -> IDS Eagle
|
||||
94 -> Pinnacle PCTV Sat [11bd:001c]
|
||||
95 -> Formac ProTV II (bt878)
|
||||
96 -> MachTV
|
||||
97 -> Euresys Picolo
|
||||
98 -> ProVideo PV150 [aa00:1460,aa01:1461,aa02:1462,aa03:1463,aa04:1464,aa05:1465,aa06:1466,aa07:1467]
|
||||
99 -> AD-TVK503
|
||||
100 -> Hercules Smart TV Stereo
|
||||
101 -> Pace TV & Radio Card
|
||||
102 -> IVC-200 [0000:a155,0001:a155,0002:a155,0003:a155,0100:a155,0101:a155,0102:a155,0103:a155]
|
||||
103 -> Grand X-Guard / Trust 814PCI [0304:0102]
|
||||
104 -> Nebula Electronics DigiTV [0071:0101]
|
||||
105 -> ProVideo PV143 [aa00:1430,aa00:1431,aa00:1432,aa00:1433,aa03:1433]
|
||||
106 -> PHYTEC VD-009-X1 MiniDIN (bt878)
|
||||
107 -> PHYTEC VD-009-X1 Combi (bt878)
|
||||
108 -> PHYTEC VD-009 MiniDIN (bt878)
|
||||
109 -> PHYTEC VD-009 Combi (bt878)
|
||||
110 -> IVC-100 [ff00:a132]
|
||||
111 -> IVC-120G [ff00:a182,ff01:a182,ff02:a182,ff03:a182,ff04:a182,ff05:a182,ff06:a182,ff07:a182,ff08:a182,ff09:a182,ff0a:a182,ff0b:a182,ff0c:a182,ff0d:a182,ff0e:a182,ff0f:a182]
|
||||
112 -> pcHDTV HD-2000 TV [7063:2000]
|
||||
113 -> Twinhan DST + clones [11bd:0026,1822:0001,270f:fc00]
|
||||
114 -> Winfast VC100 [107d:6607]
|
||||
115 -> Teppro TEV-560/InterVision IV-560
|
||||
116 -> SIMUS GVC1100 [aa6a:82b2]
|
||||
117 -> NGS NGSTV+
|
||||
118 -> LMLBT4
|
||||
119 -> Tekram M205 PRO
|
||||
120 -> Conceptronic CONTVFMi
|
||||
121 -> Euresys Picolo Tetra [1805:0105,1805:0106,1805:0107,1805:0108]
|
||||
122 -> Spirit TV Tuner
|
||||
123 -> AVerMedia AVerTV DVB-T 771 [1461:0771]
|
||||
124 -> AverMedia AverTV DVB-T 761 [1461:0761]
|
||||
125 -> MATRIX Vision Sigma-SQ
|
||||
126 -> MATRIX Vision Sigma-SLC
|
||||
127 -> APAC Viewcomp 878(AMAX)
|
||||
128 -> DViCO FusionHDTV DVB-T Lite [18ac:db10]
|
||||
129 -> V-Gear MyVCD
|
||||
130 -> Super TV Tuner
|
||||
131 -> Tibet Systems 'Progress DVR' CS16
|
||||
132 -> Kodicom 4400R (master)
|
||||
133 -> Kodicom 4400R (slave)
|
||||
134 -> Adlink RTV24
|
||||
135 -> DViCO FusionHDTV 5 Lite [18ac:d500]
|
||||
136 -> Acorp Y878F [9511:1540]
|
||||
137 -> Conceptronic CTVFMi v2
|
||||
138 -> Prolink Pixelview PV-BT878P+ (Rev.2E)
|
||||
139 -> Prolink PixelView PlayTV MPEG2 PV-M4900
|
||||
140 -> Osprey 440 [0070:ff07]
|
||||
141 -> Asound Skyeye PCTV
|
||||
|
|
|
@ -1,32 +1,37 @@
|
|||
card=0 - UNKNOWN/GENERIC
|
||||
card=1 - Hauppauge WinTV 34xxx models
|
||||
card=2 - GDI Black Gold
|
||||
card=3 - PixelView
|
||||
card=4 - ATI TV Wonder Pro
|
||||
card=5 - Leadtek Winfast 2000XP Expert
|
||||
card=6 - AverTV Studio 303 (M126)
|
||||
card=7 - MSI TV-@nywhere Master
|
||||
card=8 - Leadtek Winfast DV2000
|
||||
card=9 - Leadtek PVR 2000
|
||||
card=10 - IODATA GV-VCP3/PCI
|
||||
card=11 - Prolink PlayTV PVR
|
||||
card=12 - ASUS PVR-416
|
||||
card=13 - MSI TV-@nywhere
|
||||
card=14 - KWorld/VStream XPert DVB-T
|
||||
card=15 - DViCO FusionHDTV DVB-T1
|
||||
card=16 - KWorld LTV883RF
|
||||
card=17 - DViCO FusionHDTV 3 Gold-Q
|
||||
card=18 - Hauppauge Nova-T DVB-T
|
||||
card=19 - Conexant DVB-T reference design
|
||||
card=20 - Provideo PV259
|
||||
card=21 - DViCO FusionHDTV DVB-T Plus
|
||||
card=22 - digitalnow DNTV Live! DVB-T
|
||||
card=23 - pcHDTV HD3000 HDTV
|
||||
card=24 - Hauppauge WinTV 28xxx (Roslyn) models
|
||||
card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC)
|
||||
card=26 - IODATA GV/BCTV7E
|
||||
card=27 - PixelView PlayTV Ultra Pro (Stereo)
|
||||
card=28 - DViCO FusionHDTV 3 Gold-T
|
||||
card=29 - ADS Tech Instant TV DVB-T PCI
|
||||
card=30 - TerraTec Cinergy 1400 DVB-T
|
||||
card=31 - DViCO FusionHDTV 5 Gold
|
||||
0 -> UNKNOWN/GENERIC
|
||||
1 -> Hauppauge WinTV 34xxx models [0070:3400,0070:3401]
|
||||
2 -> GDI Black Gold [14c7:0106,14c7:0107]
|
||||
3 -> PixelView [1554:4811]
|
||||
4 -> ATI TV Wonder Pro [1002:00f8]
|
||||
5 -> Leadtek Winfast 2000XP Expert [107d:6611,107d:6613]
|
||||
6 -> AverTV Studio 303 (M126) [1461:000b]
|
||||
7 -> MSI TV-@nywhere Master [1462:8606]
|
||||
8 -> Leadtek Winfast DV2000 [107d:6620]
|
||||
9 -> Leadtek PVR 2000 [107d:663b,107d:663C]
|
||||
10 -> IODATA GV-VCP3/PCI [10fc:d003]
|
||||
11 -> Prolink PlayTV PVR
|
||||
12 -> ASUS PVR-416 [1043:4823]
|
||||
13 -> MSI TV-@nywhere
|
||||
14 -> KWorld/VStream XPert DVB-T [17de:08a6]
|
||||
15 -> DViCO FusionHDTV DVB-T1 [18ac:db00]
|
||||
16 -> KWorld LTV883RF
|
||||
17 -> DViCO FusionHDTV 3 Gold-Q [18ac:d810]
|
||||
18 -> Hauppauge Nova-T DVB-T [0070:9002]
|
||||
19 -> Conexant DVB-T reference design [14f1:0187]
|
||||
20 -> Provideo PV259 [1540:2580]
|
||||
21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10]
|
||||
22 -> pcHDTV HD3000 HDTV [7063:3000]
|
||||
23 -> digitalnow DNTV Live! DVB-T [17de:a8a6]
|
||||
24 -> Hauppauge WinTV 28xxx (Roslyn) models [0070:2801]
|
||||
25 -> Digital-Logic MICROSPACE Entertainment Center (MEC) [14f1:0342]
|
||||
26 -> IODATA GV/BCTV7E [10fc:d035]
|
||||
27 -> PixelView PlayTV Ultra Pro (Stereo)
|
||||
28 -> DViCO FusionHDTV 3 Gold-T [18ac:d820]
|
||||
29 -> ADS Tech Instant TV DVB-T PCI [1421:0334]
|
||||
30 -> TerraTec Cinergy 1400 DVB-T [153b:1166]
|
||||
31 -> DViCO FusionHDTV 5 Gold [18ac:d500]
|
||||
32 -> AverMedia UltraTV Media Center PCI 550 [1461:8011]
|
||||
33 -> Kworld V-Stream Xpert DVD
|
||||
34 -> ATI HDTV Wonder [1002:a101]
|
||||
35 -> WinFast DTV1000-T [107d:665f]
|
||||
36 -> AVerTV 303 (M126) [1461:000a]
|
||||
|
|
|
@ -0,0 +1,10 @@
|
|||
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
||||
1 -> Unknown EM2820/2840 video grabber (em2820/em2840)
|
||||
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
||||
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
||||
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200]
|
||||
5 -> MSI VOX USB 2.0 (em2820/em2840) [eb1a:2820]
|
||||
6 -> Terratec Cinergy 200 USB (em2800)
|
||||
7 -> Leadtek Winfast USB II (em2800)
|
||||
8 -> Kworld USB2800 (em2800)
|
||||
9 -> Pinnacle Dazzle DVC 90 (em2820/em2840) [2304:0207]
|
|
@ -6,10 +6,10 @@
|
|||
5 -> SKNet Monster TV [1131:4e85]
|
||||
6 -> Tevion MD 9717
|
||||
7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01]
|
||||
8 -> Terratec Cinergy 400 TV [153B:1142]
|
||||
8 -> Terratec Cinergy 400 TV [153b:1142]
|
||||
9 -> Medion 5044
|
||||
10 -> Kworld/KuroutoShikou SAA7130-TVPCI
|
||||
11 -> Terratec Cinergy 600 TV [153B:1143]
|
||||
11 -> Terratec Cinergy 600 TV [153b:1143]
|
||||
12 -> Medion 7134 [16be:0003]
|
||||
13 -> Typhoon TV+Radio 90031
|
||||
14 -> ELSA EX-VISION 300TV [1048:226b]
|
||||
|
@ -36,8 +36,8 @@
|
|||
35 -> AverMedia AverTV Studio 305 [1461:2115]
|
||||
36 -> UPMOST PURPLE TV [12ab:0800]
|
||||
37 -> Items MuchTV Plus / IT-005
|
||||
38 -> Terratec Cinergy 200 TV [153B:1152]
|
||||
39 -> LifeView FlyTV Platinum Mini [5168:0212]
|
||||
38 -> Terratec Cinergy 200 TV [153b:1152]
|
||||
39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212]
|
||||
40 -> Compro VideoMate TV PVR/FM [185b:c100]
|
||||
41 -> Compro VideoMate TV Gold+ [185b:c100]
|
||||
42 -> Sabrent SBT-TVFM (saa7130)
|
||||
|
@ -46,7 +46,7 @@
|
|||
45 -> Avermedia AVerTV Studio 307 [1461:9715]
|
||||
46 -> AVerMedia Cardbus TV/Radio (E500) [1461:d6ee]
|
||||
47 -> Terratec Cinergy 400 mobile [153b:1162]
|
||||
48 -> Terratec Cinergy 600 TV MK3 [153B:1158]
|
||||
48 -> Terratec Cinergy 600 TV MK3 [153b:1158]
|
||||
49 -> Compro VideoMate Gold+ Pal [185b:c200]
|
||||
50 -> Pinnacle PCTV 300i DVB-T + PAL [11bd:002d]
|
||||
51 -> ProVideo PV952 [1540:9524]
|
||||
|
@ -56,12 +56,27 @@
|
|||
55 -> LifeView FlyDVB-T DUO [5168:0502,5168:0306]
|
||||
56 -> Avermedia AVerTV 307 [1461:a70a]
|
||||
57 -> Avermedia AVerTV GO 007 FM [1461:f31f]
|
||||
58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0370]
|
||||
58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0370,1421:1370]
|
||||
59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
|
||||
60 -> Typhoon DVB-T Duo Digital/Analog Cardbus [4e42:0502]
|
||||
61 -> Philips TOUGH DVB-T reference design [1131:2004]
|
||||
62 -> Compro VideoMate TV Gold+II
|
||||
63 -> Kworld Xpert TV PVR7134
|
||||
64 -> FlyTV mini Asus Digimatrix [1043:0210,1043:0210]
|
||||
64 -> FlyTV mini Asus Digimatrix [1043:0210]
|
||||
65 -> V-Stream Studio TV Terminator
|
||||
66 -> Yuan TUN-900 (saa7135)
|
||||
67 -> Beholder BeholdTV 409 FM [0000:4091]
|
||||
68 -> GoTView 7135 PCI [5456:7135]
|
||||
69 -> Philips EUROPA V3 reference design [1131:2004]
|
||||
70 -> Compro Videomate DVB-T300 [185b:c900]
|
||||
71 -> Compro Videomate DVB-T200 [185b:c901]
|
||||
72 -> RTD Embedded Technologies VFG7350 [1435:7350]
|
||||
73 -> RTD Embedded Technologies VFG7330 [1435:7330]
|
||||
74 -> LifeView FlyTV Platinum Mini2 [14c0:1212]
|
||||
75 -> AVerMedia AVerTVHD MCE A180 [1461:1044]
|
||||
76 -> SKNet MonsterTV Mobile [1131:4ee9]
|
||||
77 -> Pinnacle PCTV 110i (saa7133) [11bd:002e]
|
||||
78 -> ASUSTeK P7131 Dual [1043:4862]
|
||||
79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)
|
||||
80 -> ASUS Digimatrix TV [1043:0210]
|
||||
81 -> Philips Tiger reference design [1131:2018]
|
||||
|
|
|
@ -53,7 +53,7 @@ tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3)
|
|||
tuner=52 - Thomson DDT 7610 (ATSC/NTSC)
|
||||
tuner=53 - Philips FQ1286
|
||||
tuner=54 - tda8290+75
|
||||
tuner=55 - LG PAL (TAPE series)
|
||||
tuner=55 - TCL 2002MB
|
||||
tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
|
||||
tuner=57 - Philips FQ1236A MK4
|
||||
tuner=58 - Ymec TVision TVF-8531MF/8831MF/8731MF
|
||||
|
@ -65,3 +65,5 @@ tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
|
|||
tuner=64 - LG TDVS-H062F/TUA6034
|
||||
tuner=65 - Ymec TVF66T5-B/DFF
|
||||
tuner=66 - LG NTSC (TALN mini series)
|
||||
tuner=67 - Philips TD1316 Hybrid Tuner
|
||||
tuner=68 - Philips TUV1236D ATSC/NTSC dual in
|
||||
|
|
|
@ -17,9 +17,9 @@ audio
|
|||
- The chip specs for the on-chip TV sound decoder are next
|
||||
to useless :-/
|
||||
- Neverless the builtin TV sound decoder starts working now,
|
||||
at least for PAL-BG. Other TV norms need other code ...
|
||||
FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
|
||||
USING.
|
||||
at least for PAL-BG. Other TV norms need other code ...
|
||||
FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
|
||||
USING.
|
||||
- Most tuner chips do provide mono sound, which may or may not
|
||||
be useable depending on the board design. With the Hauppauge
|
||||
cards it works, so there is mono sound available as fallback.
|
||||
|
@ -65,5 +65,5 @@ Have fun,
|
|||
|
||||
Gerd
|
||||
|
||||
--
|
||||
--
|
||||
Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
|
||||
|
|
|
@ -78,5 +78,5 @@ Have fun,
|
|||
|
||||
Gerd
|
||||
|
||||
--
|
||||
--
|
||||
Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
|
||||
|
|
|
@ -149,11 +149,11 @@ Lifeview Flyvideo Series:
|
|||
2) There is a print on the PCB:
|
||||
LR25 = Flyvideo (Zoran ZR36120, SAA7110A)
|
||||
LR26 Rev.N = Flyvideo II (Bt848)
|
||||
Rev.O = Flyvideo II (Bt878)
|
||||
Rev.O = Flyvideo II (Bt878)
|
||||
LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110)
|
||||
LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only)
|
||||
LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID)
|
||||
Rev.W = Flyvideo 98 (no eeprom)
|
||||
Rev.W = Flyvideo 98 (no eeprom)
|
||||
LR51 Rev.E = Flyvideo 98 EZ (capture only)
|
||||
LR90 = Flyvideo 2000 (Bt878)
|
||||
Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard)
|
||||
|
@ -163,7 +163,7 @@ Lifeview Flyvideo Series:
|
|||
LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134)
|
||||
LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
|
||||
LR138 Rev.C= Flyvideo 2000 (SAA7130)
|
||||
or Flyvideo 3000 (SAA7134) w/Stereo TV
|
||||
or Flyvideo 3000 (SAA7134) w/Stereo TV
|
||||
These exist in variations w/FM and w/Remote sometimes denoted
|
||||
by suffixes "FM" and "R".
|
||||
3) You have a laptop (miniPCI card):
|
||||
|
@ -197,7 +197,7 @@ Typhoon TV card series:
|
|||
50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B)
|
||||
50681 "TV Tuner PCI Pal I" (variant of 50680)
|
||||
50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q)
|
||||
Note: The package has a picture of CPH05x (which would be a real TView)
|
||||
Note: The package has a picture of CPH05x (which would be a real TView)
|
||||
50683 "TV Tuner PCI SECAM" (variant of 50680)
|
||||
50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D)
|
||||
50686 "TV Tuner" = KNC1 TV Station
|
||||
|
@ -418,9 +418,9 @@ Lifetec/Medion/Tevion/Aldi
|
|||
--------------------------
|
||||
LT9306/MD9306 = CPH061
|
||||
LT9415/MD9415 = LR90 Rev.F or Rev.G
|
||||
MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
|
||||
MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
|
||||
MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
|
||||
MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
|
||||
MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
|
||||
MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
|
||||
|
||||
Modular Technologies (www.modulartech.com) UK
|
||||
---------------------------------------------
|
||||
|
@ -453,10 +453,10 @@ Technisat
|
|||
Discos ADR PC-Karte ISA (no TV!)
|
||||
Discos ADR PC-Karte PCI (probably no TV?)
|
||||
Techni-PC-Sat (Sat. analog)
|
||||
Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
|
||||
Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
|
||||
Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio)
|
||||
Mediafocus II (saa7146, Sat. analog)
|
||||
SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
|
||||
SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
|
||||
SkyStar 1 DVB (AV7110) = Technotrend Premium
|
||||
SkyStar 2 DVB (B2C2) (=Sky2PC)
|
||||
|
||||
|
|
|
@ -42,9 +42,9 @@ bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
|
|||
the Subsystem ID in the second line, looks like this:
|
||||
|
||||
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
|
||||
Subsystem: Hauppauge computer works Inc. WinTV/GO
|
||||
Flags: bus master, medium devsel, latency 32, IRQ 5
|
||||
Memory at e2000000 (32-bit, prefetchable) [size=4K]
|
||||
Subsystem: Hauppauge computer works Inc. WinTV/GO
|
||||
Flags: bus master, medium devsel, latency 32, IRQ 5
|
||||
Memory at e2000000 (32-bit, prefetchable) [size=4K]
|
||||
|
||||
only bt878-based cards can have a subsystem ID (which does not mean
|
||||
that every card really has one). bt848 cards can't have a Subsystem
|
||||
|
|
|
@ -27,9 +27,9 @@ information out of a register+stack dump printed by the kernel on
|
|||
protection faults (so-called "kernel oops").
|
||||
|
||||
If you run into some kind of deadlock, you can try to dump a call trace
|
||||
for each process using sysrq-t (see Documentation/sysrq.txt). ksymoops
|
||||
will translate these dumps into kernel symbols too. This way it is
|
||||
possible to figure where *exactly* some process in "D" state is stuck.
|
||||
for each process using sysrq-t (see Documentation/sysrq.txt).
|
||||
This way it is possible to figure where *exactly* some process in "D"
|
||||
state is stuck.
|
||||
|
||||
I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
|
||||
for some people. Thus probably a small buglet left somewhere in bttv
|
||||
|
|
|
@ -61,8 +61,8 @@ line for your board. The important fields are these two:
|
|||
struct tvcard
|
||||
{
|
||||
[ ... ]
|
||||
u32 gpiomask;
|
||||
u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
|
||||
u32 gpiomask;
|
||||
u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
|
||||
};
|
||||
|
||||
gpiomask specifies which pins are used to control the audio mux chip.
|
||||
|
@ -126,11 +126,11 @@ muxsel - video mux, input->registervalue mapping
|
|||
pll - same as pll= insmod option
|
||||
tuner_type - same as tuner= insmod option
|
||||
*_modulename - hint whenever some card needs this or that audio
|
||||
module loaded to work properly.
|
||||
module loaded to work properly.
|
||||
has_radio - whenever this TV card has a radio tuner.
|
||||
no_msp34xx - "1" disables loading of msp3400.o module
|
||||
no_tda9875 - "1" disables loading of tda9875.o module
|
||||
needs_tvaudio - set to "1" to load tvaudio.o module
|
||||
no_tda9875 - "1" disables loading of tda9875.o module
|
||||
needs_tvaudio - set to "1" to load tvaudio.o module
|
||||
|
||||
If some config item is specified both from the tvcards array and as
|
||||
insmod option, the insmod option takes precedence.
|
||||
|
@ -144,5 +144,5 @@ Good luck,
|
|||
|
||||
PS: If you have a new working entry, mail it to me.
|
||||
|
||||
--
|
||||
--
|
||||
Gerd Knorr <kraxel@bytesex.org>
|
||||
|
|
|
@ -21,7 +21,7 @@ SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
|
|||
J= NTSC-Japan
|
||||
L= Secam LL
|
||||
M= BG+I+DK
|
||||
N= NTSC
|
||||
N= NTSC
|
||||
Q= BG+I+DK+LL
|
||||
[89]: ?
|
||||
[125]:
|
||||
|
@ -96,7 +96,7 @@ LG Innotek Tuner:
|
|||
TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
|
||||
TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8)
|
||||
TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69)
|
||||
Suffix:
|
||||
Suffix:
|
||||
P= Standard phono female socket
|
||||
D= IEC female socket
|
||||
F= F-connector
|
||||
|
|
|
@ -10,33 +10,33 @@ bt878:
|
|||
------------------------------------------------------------------------------
|
||||
|
||||
saa7134:
|
||||
/* LifeView FlyTV Platinum FM (LR214WF) */
|
||||
/* "Peter Missel <peter.missel@onlinehome.de> */
|
||||
.name = "LifeView FlyTV Platinum FM",
|
||||
/* GP27 MDT2005 PB4 pin 10 */
|
||||
/* GP26 MDT2005 PB3 pin 9 */
|
||||
/* GP25 MDT2005 PB2 pin 8 */
|
||||
/* GP23 MDT2005 PB1 pin 7 */
|
||||
/* GP22 MDT2005 PB0 pin 6 */
|
||||
/* GP21 MDT2005 PB5 pin 11 */
|
||||
/* GP20 MDT2005 PB6 pin 12 */
|
||||
/* GP19 MDT2005 PB7 pin 13 */
|
||||
/* nc MDT2005 PA3 pin 2 */
|
||||
/* Remote MDT2005 PA2 pin 1 */
|
||||
/* GP18 MDT2005 PA1 pin 18 */
|
||||
/* nc MDT2005 PA0 pin 17 strap low */
|
||||
/* LifeView FlyTV Platinum FM (LR214WF) */
|
||||
/* "Peter Missel <peter.missel@onlinehome.de> */
|
||||
.name = "LifeView FlyTV Platinum FM",
|
||||
/* GP27 MDT2005 PB4 pin 10 */
|
||||
/* GP26 MDT2005 PB3 pin 9 */
|
||||
/* GP25 MDT2005 PB2 pin 8 */
|
||||
/* GP23 MDT2005 PB1 pin 7 */
|
||||
/* GP22 MDT2005 PB0 pin 6 */
|
||||
/* GP21 MDT2005 PB5 pin 11 */
|
||||
/* GP20 MDT2005 PB6 pin 12 */
|
||||
/* GP19 MDT2005 PB7 pin 13 */
|
||||
/* nc MDT2005 PA3 pin 2 */
|
||||
/* Remote MDT2005 PA2 pin 1 */
|
||||
/* GP18 MDT2005 PA1 pin 18 */
|
||||
/* nc MDT2005 PA0 pin 17 strap low */
|
||||
|
||||
/* GP17 Strap "GP7"=High */
|
||||
/* GP16 Strap "GP6"=High
|
||||
0=Radio 1=TV
|
||||
Drives SA630D ENCH1 and HEF4052 A1 pins
|
||||
to do FM radio through SIF input */
|
||||
/* GP15 nc */
|
||||
/* GP14 nc */
|
||||
/* GP13 nc */
|
||||
/* GP12 Strap "GP5" = High */
|
||||
/* GP11 Strap "GP4" = High */
|
||||
/* GP10 Strap "GP3" = High */
|
||||
/* GP09 Strap "GP2" = Low */
|
||||
/* GP08 Strap "GP1" = Low */
|
||||
/* GP07.00 nc */
|
||||
/* GP17 Strap "GP7"=High */
|
||||
/* GP16 Strap "GP6"=High
|
||||
0=Radio 1=TV
|
||||
Drives SA630D ENCH1 and HEF4052 A1 pins
|
||||
to do FM radio through SIF input */
|
||||
/* GP15 nc */
|
||||
/* GP14 nc */
|
||||
/* GP13 nc */
|
||||
/* GP12 Strap "GP5" = High */
|
||||
/* GP11 Strap "GP4" = High */
|
||||
/* GP10 Strap "GP3" = High */
|
||||
/* GP09 Strap "GP2" = Low */
|
||||
/* GP08 Strap "GP1" = Low */
|
||||
/* GP07.00 nc */
|
||||
|
|
|
@ -13,12 +13,13 @@ This optimization is more critical now as bigger and bigger physical memories
|
|||
Users can use the huge page support in Linux kernel by either using the mmap
|
||||
system call or standard SYSv shared memory system calls (shmget, shmat).
|
||||
|
||||
First the Linux kernel needs to be built with CONFIG_HUGETLB_PAGE (present
|
||||
under Processor types and feature) and CONFIG_HUGETLBFS (present under file
|
||||
system option on config menu) config options.
|
||||
First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
|
||||
(present under "File systems") and CONFIG_HUGETLB_PAGE (selected
|
||||
automatically when CONFIG_HUGETLBFS is selected) configuration
|
||||
options.
|
||||
|
||||
The kernel built with hugepage support should show the number of configured
|
||||
hugepages in the system by running the "cat /proc/meminfo" command.
|
||||
hugepages in the system by running the "cat /proc/meminfo" command.
|
||||
|
||||
/proc/meminfo also provides information about the total number of hugetlb
|
||||
pages configured in the kernel. It also displays information about the
|
||||
|
@ -38,19 +39,19 @@ in the kernel.
|
|||
|
||||
/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
|
||||
pages in the kernel. Super user can dynamically request more (or free some
|
||||
pre-configured) hugepages.
|
||||
The allocation( or deallocation) of hugetlb pages is posible only if there are
|
||||
pre-configured) hugepages.
|
||||
The allocation (or deallocation) of hugetlb pages is possible only if there are
|
||||
enough physically contiguous free pages in system (freeing of hugepages is
|
||||
possible only if there are enough hugetlb pages free that can be transfered
|
||||
possible only if there are enough hugetlb pages free that can be transfered
|
||||
back to regular memory pool).
|
||||
|
||||
Pages that are used as hugetlb pages are reserved inside the kernel and can
|
||||
not be used for other purposes.
|
||||
not be used for other purposes.
|
||||
|
||||
Once the kernel with Hugetlb page support is built and running, a user can
|
||||
use either the mmap system call or shared memory system calls to start using
|
||||
the huge pages. It is required that the system administrator preallocate
|
||||
enough memory for huge page purposes.
|
||||
enough memory for huge page purposes.
|
||||
|
||||
Use the following command to dynamically allocate/deallocate hugepages:
|
||||
|
||||
|
@ -80,9 +81,9 @@ memory (huge pages) allowed for that filesystem (/mnt/huge). The size is
|
|||
rounded down to HPAGE_SIZE. The option nr_inode sets the maximum number of
|
||||
inodes that /mnt/huge can use. If the size or nr_inode options are not
|
||||
provided on command line then no limits are set. For size and nr_inodes
|
||||
options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For
|
||||
example, size=2K has the same meaning as size=2048. An example is given at
|
||||
the end of this document.
|
||||
options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For
|
||||
example, size=2K has the same meaning as size=2048. An example is given at
|
||||
the end of this document.
|
||||
|
||||
read and write system calls are not supported on files that reside on hugetlb
|
||||
file systems.
|
||||
|
|
64
MAINTAINERS
64
MAINTAINERS
|
@ -297,6 +297,11 @@ P: Richard Purdie
|
|||
M: rpurdie@rpsys.net
|
||||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dirk Opfer
|
||||
M: dirk@opfer-online.de
|
||||
S: Maintained
|
||||
|
||||
ARM/PLEB SUPPORT
|
||||
P: Peter Chubb
|
||||
M: pleb@gelato.unsw.edu.au
|
||||
|
@ -910,6 +915,15 @@ L: linux-fbdev-devel@lists.sourceforge.net
|
|||
W: http://linux-fbdev.sourceforge.net/
|
||||
S: Maintained
|
||||
|
||||
FREESCALE SOC FS_ENET DRIVER
|
||||
P: Pantelis Antoniou
|
||||
M: pantelis.antoniou@gmail.com
|
||||
P: Vitaly Bordug
|
||||
M: vbordug@ru.mvista.com
|
||||
L: linuxppc-embedded@ozlabs.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
FILE LOCKING (flock() and fcntl()/lockf())
|
||||
P: Matthew Wilcox
|
||||
M: matthew@wil.cx
|
||||
|
@ -1063,6 +1077,26 @@ P: Jaroslav Kysela
|
|||
M: perex@suse.cz
|
||||
S: Maintained
|
||||
|
||||
HPET: High Precision Event Timers driver (hpet.c)
|
||||
P: Clemens Ladisch
|
||||
M: clemens@ladisch.de
|
||||
S: Maintained
|
||||
|
||||
HPET: i386
|
||||
P: Venkatesh Pallipadi (Venki)
|
||||
M: venkatesh.pallipadi@intel.com
|
||||
S: Maintained
|
||||
|
||||
HPET: x86_64
|
||||
P: Andi Kleen and Vojtech Pavlik
|
||||
M: ak@muc.de and vojtech@suse.cz
|
||||
S: Maintained
|
||||
|
||||
HPET: ACPI hpet.c
|
||||
P: Bob Picco
|
||||
M: bob.picco@hp.com
|
||||
S: Maintained
|
||||
|
||||
HPFS FILESYSTEM
|
||||
P: Mikulas Patocka
|
||||
M: mikulas@artax.karlin.mff.cuni.cz
|
||||
|
@ -1296,6 +1330,24 @@ M: john.ronciak@intel.com
|
|||
W: http://sourceforge.net/projects/e1000/
|
||||
S: Supported
|
||||
|
||||
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
|
||||
P: Yi Zhu
|
||||
M: yi.zhu@intel.com
|
||||
P: James Ketrenos
|
||||
M: jketreno@linux.intel.com
|
||||
L: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
|
||||
W: http://ipw2100.sourceforge.net
|
||||
S: Supported
|
||||
|
||||
INTEL PRO/WIRELESS 2915ABG NETWORK CONNECTION SUPPORT
|
||||
P: Yi Zhu
|
||||
M: yi.zhu@intel.com
|
||||
P: James Ketrenos
|
||||
M: jketreno@linux.intel.com
|
||||
L: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
|
||||
W: http://ipw2200.sourceforge.net
|
||||
S: Supported
|
||||
|
||||
IOC3 DRIVER
|
||||
P: Ralf Baechle
|
||||
M: ralf@linux-mips.org
|
||||
|
@ -2037,6 +2089,12 @@ P: Matt Mackall
|
|||
M: mpm@selenic.com
|
||||
S: Maintained
|
||||
|
||||
RAPIDIO SUBSYSTEM
|
||||
P: Matt Porter
|
||||
M: mporter@kernel.crashing.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
REAL TIME CLOCK DRIVER
|
||||
P: Paul Gortmaker
|
||||
M: p_gortmaker@yahoo.com
|
||||
|
@ -2441,10 +2499,10 @@ L: linux-kernel@vger.kernel.org
|
|||
S: Maintained
|
||||
|
||||
TRIVIAL PATCHES
|
||||
P: Rusty Russell
|
||||
M: trivial@rustcorp.com.au
|
||||
P: Adrian Bunk
|
||||
M: trivial@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/
|
||||
S: Maintained
|
||||
|
||||
TMS380 TOKEN-RING NETWORK DRIVER
|
||||
|
|
10
Makefile
10
Makefile
|
@ -346,7 +346,8 @@ AFLAGS_KERNEL =
|
|||
# Use LINUXINCLUDE when you must reference the include/ directory.
|
||||
# Needed to be compatible with the O= option
|
||||
LINUXINCLUDE := -Iinclude \
|
||||
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)
|
||||
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
|
||||
-imacros include/linux/autoconf.h
|
||||
|
||||
CPPFLAGS := -D__KERNEL__ $(LINUXINCLUDE)
|
||||
|
||||
|
@ -582,7 +583,7 @@ export MODLIB
|
|||
|
||||
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/
|
||||
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
|
||||
|
||||
vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
|
||||
$(core-y) $(core-m) $(drivers-y) $(drivers-m) \
|
||||
|
@ -1249,11 +1250,6 @@ tags: FORCE
|
|||
# Scripts to check various things for consistency
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
configcheck:
|
||||
find * $(RCS_FIND_IGNORE) \
|
||||
-name '*.[hcS]' -type f -print | sort \
|
||||
| xargs $(PERL) -w scripts/checkconfig.pl
|
||||
|
||||
includecheck:
|
||||
find * $(RCS_FIND_IGNORE) \
|
||||
-name '*.[hcS]' -type f -print | sort \
|
||||
|
|
|
@ -43,21 +43,17 @@
|
|||
#include "proto.h"
|
||||
#include "pci_impl.h"
|
||||
|
||||
void default_idle(void)
|
||||
{
|
||||
barrier();
|
||||
}
|
||||
|
||||
void
|
||||
cpu_idle(void)
|
||||
{
|
||||
set_thread_flag(TIF_POLLING_NRFLAG);
|
||||
|
||||
while (1) {
|
||||
void (*idle)(void) = default_idle;
|
||||
/* FIXME -- EV6 and LCA45 know how to power down
|
||||
the CPU. */
|
||||
|
||||
while (!need_resched())
|
||||
idle();
|
||||
cpu_relax();
|
||||
schedule();
|
||||
}
|
||||
}
|
||||
|
|
|
@ -324,7 +324,7 @@ menu "Kernel Features"
|
|||
|
||||
config SMP
|
||||
bool "Symmetric Multi-Processing (EXPERIMENTAL)"
|
||||
depends on EXPERIMENTAL && BROKEN #&& n
|
||||
depends on EXPERIMENTAL && REALVIEW_MPCORE
|
||||
help
|
||||
This enables support for systems with more than one CPU. If you have
|
||||
a system with only one CPU, like most personal computers, say N. If
|
||||
|
@ -349,6 +349,23 @@ config NR_CPUS
|
|||
depends on SMP
|
||||
default "4"
|
||||
|
||||
config HOTPLUG_CPU
|
||||
bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
|
||||
depends on SMP && HOTPLUG && EXPERIMENTAL
|
||||
help
|
||||
Say Y here to experiment with turning CPUs off and on. CPUs
|
||||
can be controlled through /sys/devices/system/cpu.
|
||||
|
||||
config LOCAL_TIMERS
|
||||
bool "Use local timer interrupts"
|
||||
depends on SMP && REALVIEW_MPCORE
|
||||
default y
|
||||
help
|
||||
Enable support for local timers on SMP platforms, rather then the
|
||||
legacy IPI broadcast method. Local timers allows the system
|
||||
accounting to be spread across the timer interval, preventing a
|
||||
"thundering herd" at every timer tick.
|
||||
|
||||
config PREEMPT
|
||||
bool "Preemptible Kernel (EXPERIMENTAL)"
|
||||
depends on EXPERIMENTAL
|
||||
|
@ -578,7 +595,7 @@ config FPE_NWFPE
|
|||
|
||||
config FPE_NWFPE_XP
|
||||
bool "Support extended precision"
|
||||
depends on FPE_NWFPE && !CPU_BIG_ENDIAN
|
||||
depends on FPE_NWFPE
|
||||
help
|
||||
Say Y to include 80-bit support in the kernel floating-point
|
||||
emulator. Otherwise, only 32 and 64-bit support is compiled in.
|
||||
|
@ -697,8 +714,7 @@ source "drivers/acorn/block/Kconfig"
|
|||
|
||||
if PCMCIA || ARCH_CLPS7500 || ARCH_IOP3XX || ARCH_IXP4XX \
|
||||
|| ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
|
||||
|| ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE \
|
||||
|| MACH_MP1000
|
||||
|| ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE
|
||||
source "drivers/ide/Kconfig"
|
||||
endif
|
||||
|
||||
|
|
|
@ -38,6 +38,7 @@ comma = ,
|
|||
# macro, but instead defines a whole series of macros which makes
|
||||
# testing for a specific architecture or later rather impossible.
|
||||
arch-$(CONFIG_CPU_32v6) :=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
|
||||
arch-$(CONFIG_CPU_32v6K) :=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k)
|
||||
arch-$(CONFIG_CPU_32v5) :=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4)
|
||||
arch-$(CONFIG_CPU_32v4) :=-D__LINUX_ARM_ARCH__=4 -march=armv4
|
||||
arch-$(CONFIG_CPU_32v3) :=-D__LINUX_ARM_ARCH__=3 -march=armv3
|
||||
|
@ -143,7 +144,7 @@ drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
|
|||
drivers-$(CONFIG_ARCH_CLPS7500) += drivers/acorn/char/
|
||||
drivers-$(CONFIG_ARCH_L7200) += drivers/acorn/char/
|
||||
|
||||
libs-y += arch/arm/lib/
|
||||
libs-y := arch/arm/lib/ $(libs-y)
|
||||
|
||||
# Default target when executing plain make
|
||||
ifeq ($(CONFIG_XIP_KERNEL),y)
|
||||
|
|
|
@ -39,8 +39,7 @@
|
|||
defined(CONFIG_ARCH_IXP4XX) || \
|
||||
defined(CONFIG_ARCH_IXP2000) || \
|
||||
defined(CONFIG_ARCH_LH7A40X) || \
|
||||
defined(CONFIG_ARCH_OMAP) || \
|
||||
defined(CONFIG_MACH_MP1000)
|
||||
defined(CONFIG_ARCH_OMAP)
|
||||
.macro loadsp, rb
|
||||
addruart \rb
|
||||
.endm
|
||||
|
|
|
@ -283,8 +283,14 @@ void flush_window(void)
|
|||
putstr(".");
|
||||
}
|
||||
|
||||
#ifndef arch_error
|
||||
#define arch_error(x)
|
||||
#endif
|
||||
|
||||
static void error(char *x)
|
||||
{
|
||||
arch_error(x);
|
||||
|
||||
putstr("\n\n");
|
||||
putstr(x);
|
||||
putstr("\n\n -- System halted");
|
||||
|
|
|
@ -19,12 +19,6 @@
|
|||
|
||||
#define SCOOP_REG(d,adr) (*(volatile unsigned short*)(d +(adr)))
|
||||
|
||||
/* PCMCIA to Scoop linkage structures for pxa2xx_sharpsl.c
|
||||
There is no easy way to link multiple scoop devices into one
|
||||
single entity for the pxa2xx_pcmcia device */
|
||||
int scoop_num;
|
||||
struct scoop_pcmcia_dev *scoop_devs;
|
||||
|
||||
struct scoop_dev {
|
||||
void *base;
|
||||
spinlock_t scoop_lock;
|
||||
|
|
|
@ -152,7 +152,7 @@ CONFIG_ALIGNMENT_TRAP=y
|
|||
#
|
||||
CONFIG_ZBOOT_ROM_TEXT=0x0
|
||||
CONFIG_ZBOOT_ROM_BSS=0x0
|
||||
CONFIG_CMDLINE="console=ttyS0,57600 root=/dev/nfs ip=bootp mem=64M@0x0 pci=firmware"
|
||||
CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/nfs ip=bootp mem=64M@0x0 pci=firmware"
|
||||
# CONFIG_XIP_KERNEL is not set
|
||||
|
||||
#
|
||||
|
@ -560,7 +560,7 @@ CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
|
|||
#
|
||||
CONFIG_SERIAL_8250=y
|
||||
CONFIG_SERIAL_8250_CONSOLE=y
|
||||
CONFIG_SERIAL_8250_NR_UARTS=2
|
||||
CONFIG_SERIAL_8250_NR_UARTS=3
|
||||
# CONFIG_SERIAL_8250_EXTENDED is not set
|
||||
|
||||
#
|
||||
|
|
|
@ -560,7 +560,7 @@ CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
|
|||
#
|
||||
CONFIG_SERIAL_8250=y
|
||||
CONFIG_SERIAL_8250_CONSOLE=y
|
||||
CONFIG_SERIAL_8250_NR_UARTS=2
|
||||
CONFIG_SERIAL_8250_NR_UARTS=3
|
||||
# CONFIG_SERIAL_8250_EXTENDED is not set
|
||||
|
||||
#
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
#
|
||||
# Automatically generated make config: don't edit
|
||||
# Linux kernel version: 2.6.14-rc1
|
||||
# Fri Sep 16 15:48:13 2005
|
||||
# Linux kernel version: 2.6.14-rc2
|
||||
# Thu Sep 29 14:50:10 2005
|
||||
#
|
||||
CONFIG_ARM=y
|
||||
CONFIG_MMU=y
|
||||
|
@ -12,11 +12,9 @@ CONFIG_GENERIC_CALIBRATE_DELAY=y
|
|||
#
|
||||
# Code maturity level options
|
||||
#
|
||||
CONFIG_EXPERIMENTAL=y
|
||||
# CONFIG_CLEAN_COMPILE is not set
|
||||
CONFIG_BROKEN=y
|
||||
# CONFIG_EXPERIMENTAL is not set
|
||||
CONFIG_CLEAN_COMPILE=y
|
||||
CONFIG_BROKEN_ON_SMP=y
|
||||
CONFIG_LOCK_KERNEL=y
|
||||
CONFIG_INIT_ENV_ARG_LIMIT=32
|
||||
|
||||
#
|
||||
|
@ -24,18 +22,16 @@ CONFIG_INIT_ENV_ARG_LIMIT=32
|
|||
#
|
||||
CONFIG_LOCALVERSION=""
|
||||
CONFIG_LOCALVERSION_AUTO=y
|
||||
CONFIG_SWAP=y
|
||||
# CONFIG_SWAP is not set
|
||||
CONFIG_SYSVIPC=y
|
||||
# CONFIG_POSIX_MQUEUE is not set
|
||||
# CONFIG_BSD_PROCESS_ACCT is not set
|
||||
CONFIG_SYSCTL=y
|
||||
# CONFIG_AUDIT is not set
|
||||
# CONFIG_HOTPLUG is not set
|
||||
CONFIG_HOTPLUG=y
|
||||
CONFIG_KOBJECT_UEVENT=y
|
||||
CONFIG_IKCONFIG=y
|
||||
CONFIG_IKCONFIG_PROC=y
|
||||
# CONFIG_IKCONFIG is not set
|
||||
CONFIG_INITRAMFS_SOURCE=""
|
||||
CONFIG_EMBEDDED=y
|
||||
# CONFIG_EMBEDDED is not set
|
||||
CONFIG_KALLSYMS=y
|
||||
# CONFIG_KALLSYMS_ALL is not set
|
||||
# CONFIG_KALLSYMS_EXTRA_PASS is not set
|
||||
|
@ -58,17 +54,15 @@ CONFIG_BASE_SMALL=0
|
|||
#
|
||||
CONFIG_MODULES=y
|
||||
CONFIG_MODULE_UNLOAD=y
|
||||
# CONFIG_MODULE_FORCE_UNLOAD is not set
|
||||
CONFIG_OBSOLETE_MODPARM=y
|
||||
# CONFIG_MODVERSIONS is not set
|
||||
# CONFIG_MODULE_SRCVERSION_ALL is not set
|
||||
CONFIG_KMOD=y
|
||||
# CONFIG_KMOD is not set
|
||||
|
||||
#
|
||||
# System Type
|
||||
#
|
||||
# CONFIG_ARCH_CLPS7500 is not set
|
||||
CONFIG_ARCH_CLPS711X=y
|
||||
# CONFIG_ARCH_CLPS711X is not set
|
||||
# CONFIG_ARCH_CO285 is not set
|
||||
# CONFIG_ARCH_EBSA110 is not set
|
||||
# CONFIG_ARCH_CAMELOT is not set
|
||||
|
@ -86,43 +80,43 @@ CONFIG_ARCH_CLPS711X=y
|
|||
# CONFIG_ARCH_LH7A40X is not set
|
||||
# CONFIG_ARCH_OMAP is not set
|
||||
# CONFIG_ARCH_VERSATILE is not set
|
||||
CONFIG_ARCH_REALVIEW=y
|
||||
# CONFIG_ARCH_IMX is not set
|
||||
# CONFIG_ARCH_H720X is not set
|
||||
# CONFIG_ARCH_AAEC2000 is not set
|
||||
|
||||
#
|
||||
# CLPS711X/EP721X Implementations
|
||||
# RealView platform type
|
||||
#
|
||||
# CONFIG_ARCH_AUTCPU12 is not set
|
||||
# CONFIG_ARCH_CDB89712 is not set
|
||||
# CONFIG_ARCH_CEIVA is not set
|
||||
# CONFIG_ARCH_CLEP7312 is not set
|
||||
# CONFIG_ARCH_EDB7211 is not set
|
||||
# CONFIG_ARCH_P720T is not set
|
||||
# CONFIG_ARCH_FORTUNET is not set
|
||||
CONFIG_MACH_MP1000=y
|
||||
CONFIG_MP1000_90MHZ=y
|
||||
CONFIG_MACH_REALVIEW_EB=y
|
||||
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_LV4T=y
|
||||
CONFIG_CPU_CACHE_V4=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
# CONFIG_CPU_V6 is not set
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
CONFIG_CPU_CACHE_VIVT=y
|
||||
CONFIG_CPU_COPY_V4WT=y
|
||||
CONFIG_CPU_TLB_V4WT=y
|
||||
CONFIG_CPU_COPY_V4WB=y
|
||||
CONFIG_CPU_TLB_V4WBI=y
|
||||
|
||||
#
|
||||
# Processor Features
|
||||
#
|
||||
CONFIG_ARM_THUMB=y
|
||||
# CONFIG_CPU_ICACHE_DISABLE is not set
|
||||
# CONFIG_CPU_DCACHE_DISABLE is not set
|
||||
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
|
||||
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
|
||||
CONFIG_ARM_GIC=y
|
||||
CONFIG_ICST307=y
|
||||
|
||||
#
|
||||
# Bus support
|
||||
#
|
||||
CONFIG_ARM_AMBA=y
|
||||
CONFIG_ISA_DMA_API=y
|
||||
|
||||
#
|
||||
|
@ -133,14 +127,8 @@ CONFIG_ISA_DMA_API=y
|
|||
#
|
||||
# Kernel Features
|
||||
#
|
||||
# CONFIG_SMP is not set
|
||||
CONFIG_PREEMPT=y
|
||||
# CONFIG_NO_IDLE_HZ is not set
|
||||
# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set
|
||||
CONFIG_SELECT_MEMORY_MODEL=y
|
||||
CONFIG_FLATMEM_MANUAL=y
|
||||
# CONFIG_DISCONTIGMEM_MANUAL is not set
|
||||
# CONFIG_SPARSEMEM_MANUAL is not set
|
||||
CONFIG_FLATMEM=y
|
||||
CONFIG_FLAT_NODE_MEM_MAP=y
|
||||
# CONFIG_SPARSEMEM_STATIC is not set
|
||||
|
@ -151,7 +139,7 @@ CONFIG_ALIGNMENT_TRAP=y
|
|||
#
|
||||
CONFIG_ZBOOT_ROM_TEXT=0x0
|
||||
CONFIG_ZBOOT_ROM_BSS=0x0
|
||||
CONFIG_CMDLINE="console=ttyCL,38400 root=/dev/discs/disc0/part1 ip=any cs89x0_media=rj45"
|
||||
CONFIG_CMDLINE="root=/dev/nfs nfsroot=10.1.69.3:/work/nfsroot ip=dhcp console=ttyAMA0 mem=128M"
|
||||
# CONFIG_XIP_KERNEL is not set
|
||||
|
||||
#
|
||||
|
@ -163,14 +151,14 @@ CONFIG_CMDLINE="console=ttyCL,38400 root=/dev/discs/disc0/part1 ip=any cs89x0_me
|
|||
#
|
||||
CONFIG_FPE_NWFPE=y
|
||||
# CONFIG_FPE_NWFPE_XP is not set
|
||||
# CONFIG_FPE_FASTFPE is not set
|
||||
# CONFIG_VFP is not set
|
||||
|
||||
#
|
||||
# Userspace binary formats
|
||||
#
|
||||
CONFIG_BINFMT_ELF=y
|
||||
# CONFIG_BINFMT_AOUT is not set
|
||||
CONFIG_BINFMT_MISC=y
|
||||
# CONFIG_BINFMT_MISC is not set
|
||||
# CONFIG_ARTHUR is not set
|
||||
|
||||
#
|
||||
|
@ -197,10 +185,9 @@ CONFIG_IP_FIB_HASH=y
|
|||
CONFIG_IP_PNP=y
|
||||
CONFIG_IP_PNP_DHCP=y
|
||||
CONFIG_IP_PNP_BOOTP=y
|
||||
CONFIG_IP_PNP_RARP=y
|
||||
# CONFIG_IP_PNP_RARP is not set
|
||||
# CONFIG_NET_IPIP is not set
|
||||
# CONFIG_NET_IPGRE is not set
|
||||
# CONFIG_ARPD is not set
|
||||
# CONFIG_SYN_COOKIES is not set
|
||||
# CONFIG_INET_AH is not set
|
||||
# CONFIG_INET_ESP is not set
|
||||
|
@ -210,36 +197,14 @@ CONFIG_INET_DIAG=y
|
|||
CONFIG_INET_TCP_DIAG=y
|
||||
# CONFIG_TCP_CONG_ADVANCED is not set
|
||||
CONFIG_TCP_CONG_BIC=y
|
||||
CONFIG_IPV6=y
|
||||
# CONFIG_IPV6_PRIVACY is not set
|
||||
# CONFIG_INET6_AH is not set
|
||||
# CONFIG_INET6_ESP is not set
|
||||
# CONFIG_INET6_IPCOMP is not set
|
||||
# CONFIG_INET6_TUNNEL is not set
|
||||
# CONFIG_IPV6_TUNNEL is not set
|
||||
# CONFIG_IPV6 is not set
|
||||
# CONFIG_NETFILTER is not set
|
||||
|
||||
#
|
||||
# DCCP Configuration (EXPERIMENTAL)
|
||||
#
|
||||
# CONFIG_IP_DCCP is not set
|
||||
|
||||
#
|
||||
# SCTP Configuration (EXPERIMENTAL)
|
||||
#
|
||||
# CONFIG_IP_SCTP is not set
|
||||
# CONFIG_ATM is not set
|
||||
# CONFIG_BRIDGE is not set
|
||||
# CONFIG_VLAN_8021Q is not set
|
||||
# CONFIG_DECNET is not set
|
||||
# CONFIG_LLC2 is not set
|
||||
# CONFIG_IPX is not set
|
||||
# CONFIG_ATALK is not set
|
||||
# CONFIG_X25 is not set
|
||||
# CONFIG_LAPB is not set
|
||||
# CONFIG_NET_DIVERT is not set
|
||||
# CONFIG_ECONET is not set
|
||||
# CONFIG_WAN_ROUTER is not set
|
||||
# CONFIG_NET_SCHED is not set
|
||||
# CONFIG_NET_CLS_ROUTE is not set
|
||||
|
||||
|
@ -247,7 +212,6 @@ CONFIG_IPV6=y
|
|||
# Network testing
|
||||
#
|
||||
# CONFIG_NET_PKTGEN is not set
|
||||
# CONFIG_NETFILTER_NETLINK is not set
|
||||
# CONFIG_HAMRADIO is not set
|
||||
# CONFIG_IRDA is not set
|
||||
# CONFIG_BT is not set
|
||||
|
@ -269,14 +233,10 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
|
|||
# Memory Technology Devices (MTD)
|
||||
#
|
||||
CONFIG_MTD=y
|
||||
CONFIG_MTD_DEBUG=y
|
||||
CONFIG_MTD_DEBUG_VERBOSE=3
|
||||
# CONFIG_MTD_DEBUG is not set
|
||||
# CONFIG_MTD_CONCAT is not set
|
||||
CONFIG_MTD_PARTITIONS=y
|
||||
CONFIG_MTD_REDBOOT_PARTS=m
|
||||
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-2
|
||||
CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y
|
||||
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
|
||||
# CONFIG_MTD_REDBOOT_PARTS is not set
|
||||
CONFIG_MTD_CMDLINE_PARTS=y
|
||||
# CONFIG_MTD_AFS_PARTS is not set
|
||||
|
||||
|
@ -292,45 +252,36 @@ CONFIG_MTD_BLOCK=y
|
|||
#
|
||||
# RAM/ROM/Flash chip drivers
|
||||
#
|
||||
CONFIG_MTD_CFI=m
|
||||
CONFIG_MTD_CFI=y
|
||||
# CONFIG_MTD_JEDECPROBE is not set
|
||||
CONFIG_MTD_GEN_PROBE=m
|
||||
CONFIG_MTD_CFI_ADV_OPTIONS=y
|
||||
CONFIG_MTD_CFI_NOSWAP=y
|
||||
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
|
||||
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
|
||||
CONFIG_MTD_CFI_GEOMETRY=y
|
||||
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
|
||||
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
|
||||
CONFIG_MTD_GEN_PROBE=y
|
||||
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
|
||||
CONFIG_MTD_MAP_BANK_WIDTH_1=y
|
||||
CONFIG_MTD_MAP_BANK_WIDTH_2=y
|
||||
CONFIG_MTD_MAP_BANK_WIDTH_4=y
|
||||
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
|
||||
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
|
||||
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
|
||||
# CONFIG_MTD_CFI_I1 is not set
|
||||
CONFIG_MTD_CFI_I1=y
|
||||
CONFIG_MTD_CFI_I2=y
|
||||
# CONFIG_MTD_CFI_I4 is not set
|
||||
# CONFIG_MTD_CFI_I8 is not set
|
||||
# CONFIG_MTD_OTP is not set
|
||||
CONFIG_MTD_CFI_INTELEXT=m
|
||||
# CONFIG_MTD_CFI_AMDSTD is not set
|
||||
CONFIG_MTD_CFI_INTELEXT=y
|
||||
CONFIG_MTD_CFI_AMDSTD=y
|
||||
CONFIG_MTD_CFI_AMDSTD_RETRY=0
|
||||
# CONFIG_MTD_CFI_STAA is not set
|
||||
CONFIG_MTD_CFI_UTIL=m
|
||||
CONFIG_MTD_CFI_UTIL=y
|
||||
# CONFIG_MTD_RAM is not set
|
||||
# CONFIG_MTD_ROM is not set
|
||||
# CONFIG_MTD_ABSENT is not set
|
||||
# CONFIG_MTD_OBSOLETE_CHIPS is not set
|
||||
# CONFIG_MTD_XIP is not set
|
||||
|
||||
#
|
||||
# Mapping drivers for chip access
|
||||
#
|
||||
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
|
||||
CONFIG_MTD_PHYSMAP=m
|
||||
CONFIG_MTD_PHYSMAP_START=0x0000000
|
||||
CONFIG_MTD_PHYSMAP_LEN=0x4000000
|
||||
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
|
||||
# CONFIG_MTD_ARM_INTEGRATOR is not set
|
||||
CONFIG_MTD_EDB7312=m
|
||||
# CONFIG_MTD_PHYSMAP is not set
|
||||
CONFIG_MTD_ARM_INTEGRATOR=y
|
||||
# CONFIG_MTD_EDB7312 is not set
|
||||
# CONFIG_MTD_PLATRAM is not set
|
||||
|
||||
#
|
||||
|
@ -340,7 +291,6 @@ CONFIG_MTD_EDB7312=m
|
|||
# CONFIG_MTD_PHRAM is not set
|
||||
# CONFIG_MTD_MTDRAM is not set
|
||||
# CONFIG_MTD_BLKMTD is not set
|
||||
# CONFIG_MTD_BLOCK2MTD is not set
|
||||
|
||||
#
|
||||
# Disk-On-Chip Device Drivers
|
||||
|
@ -352,12 +302,7 @@ CONFIG_MTD_EDB7312=m
|
|||
#
|
||||
# NAND Flash Device Drivers
|
||||
#
|
||||
CONFIG_MTD_NAND=y
|
||||
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
|
||||
CONFIG_MTD_NAND_MP1000=y
|
||||
CONFIG_MTD_NAND_IDS=y
|
||||
# CONFIG_MTD_NAND_DISKONCHIP is not set
|
||||
# CONFIG_MTD_NAND_NANDSIM is not set
|
||||
# CONFIG_MTD_NAND is not set
|
||||
|
||||
#
|
||||
# Parallel port support
|
||||
|
@ -372,52 +317,21 @@ CONFIG_MTD_NAND_IDS=y
|
|||
# Block devices
|
||||
#
|
||||
# CONFIG_BLK_DEV_COW_COMMON is not set
|
||||
CONFIG_BLK_DEV_LOOP=m
|
||||
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
|
||||
# CONFIG_BLK_DEV_LOOP is not set
|
||||
# CONFIG_BLK_DEV_NBD is not set
|
||||
CONFIG_BLK_DEV_RAM=y
|
||||
CONFIG_BLK_DEV_RAM_COUNT=2
|
||||
CONFIG_BLK_DEV_RAM_SIZE=16384
|
||||
CONFIG_BLK_DEV_INITRD=y
|
||||
# CONFIG_BLK_DEV_RAM is not set
|
||||
CONFIG_BLK_DEV_RAM_COUNT=16
|
||||
# CONFIG_CDROM_PKTCDVD is not set
|
||||
|
||||
#
|
||||
# IO Schedulers
|
||||
#
|
||||
CONFIG_IOSCHED_NOOP=y
|
||||
CONFIG_IOSCHED_AS=y
|
||||
# CONFIG_IOSCHED_AS is not set
|
||||
CONFIG_IOSCHED_DEADLINE=y
|
||||
CONFIG_IOSCHED_CFQ=y
|
||||
# CONFIG_IOSCHED_CFQ is not set
|
||||
# CONFIG_ATA_OVER_ETH is not set
|
||||
|
||||
#
|
||||
# ATA/ATAPI/MFM/RLL support
|
||||
#
|
||||
CONFIG_IDE=y
|
||||
CONFIG_BLK_DEV_IDE=y
|
||||
|
||||
#
|
||||
# Please see Documentation/ide.txt for help/info on IDE drives
|
||||
#
|
||||
# CONFIG_BLK_DEV_IDE_SATA is not set
|
||||
# CONFIG_BLK_DEV_HD_IDE is not set
|
||||
CONFIG_BLK_DEV_IDEDISK=y
|
||||
# CONFIG_IDEDISK_MULTI_MODE is not set
|
||||
# CONFIG_BLK_DEV_IDECD is not set
|
||||
# CONFIG_BLK_DEV_IDETAPE is not set
|
||||
# CONFIG_BLK_DEV_IDEFLOPPY is not set
|
||||
# CONFIG_IDE_TASK_IOCTL is not set
|
||||
|
||||
#
|
||||
# IDE chipset support/bugfixes
|
||||
#
|
||||
# CONFIG_IDE_GENERIC is not set
|
||||
CONFIG_IDE_ARM=y
|
||||
CONFIG_BLK_DEV_IDE_MP1000=y
|
||||
# CONFIG_BLK_DEV_IDEDMA is not set
|
||||
# CONFIG_IDEDMA_AUTO is not set
|
||||
# CONFIG_BLK_DEV_HD is not set
|
||||
|
||||
#
|
||||
# SCSI device support
|
||||
#
|
||||
|
@ -427,14 +341,7 @@ CONFIG_BLK_DEV_IDE_MP1000=y
|
|||
#
|
||||
# Multi-device support (RAID and LVM)
|
||||
#
|
||||
CONFIG_MD=y
|
||||
# CONFIG_BLK_DEV_MD is not set
|
||||
CONFIG_BLK_DEV_DM=y
|
||||
# CONFIG_DM_CRYPT is not set
|
||||
# CONFIG_DM_SNAPSHOT is not set
|
||||
# CONFIG_DM_MIRROR is not set
|
||||
# CONFIG_DM_ZERO is not set
|
||||
# CONFIG_DM_MULTIPATH is not set
|
||||
# CONFIG_MD is not set
|
||||
|
||||
#
|
||||
# Fusion MPT device support
|
||||
|
@ -444,7 +351,6 @@ CONFIG_BLK_DEV_DM=y
|
|||
#
|
||||
# IEEE 1394 (FireWire) support
|
||||
#
|
||||
# CONFIG_IEEE1394 is not set
|
||||
|
||||
#
|
||||
# I2O device support
|
||||
|
@ -468,10 +374,9 @@ CONFIG_NETDEVICES=y
|
|||
# Ethernet (10 or 100Mbit)
|
||||
#
|
||||
CONFIG_NET_ETHERNET=y
|
||||
# CONFIG_MII is not set
|
||||
# CONFIG_SMC91X is not set
|
||||
CONFIG_MII=y
|
||||
CONFIG_SMC91X=y
|
||||
# CONFIG_DM9000 is not set
|
||||
CONFIG_CS89x0=y
|
||||
|
||||
#
|
||||
# Ethernet (1000 Mbit)
|
||||
|
@ -496,8 +401,6 @@ CONFIG_CS89x0=y
|
|||
# CONFIG_WAN is not set
|
||||
# CONFIG_PPP is not set
|
||||
# CONFIG_SLIP is not set
|
||||
# CONFIG_SHAPER is not set
|
||||
# CONFIG_NETCONSOLE is not set
|
||||
# CONFIG_NETPOLL is not set
|
||||
# CONFIG_NET_POLL_CONTROLLER is not set
|
||||
|
||||
|
@ -514,17 +417,28 @@ CONFIG_INPUT=y
|
|||
#
|
||||
# Userland interfaces
|
||||
#
|
||||
# CONFIG_INPUT_MOUSEDEV is not set
|
||||
CONFIG_INPUT_MOUSEDEV=y
|
||||
CONFIG_INPUT_MOUSEDEV_PSAUX=y
|
||||
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
|
||||
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
|
||||
# CONFIG_INPUT_JOYDEV is not set
|
||||
# CONFIG_INPUT_TSDEV is not set
|
||||
# CONFIG_INPUT_EVDEV is not set
|
||||
CONFIG_INPUT_EVBUG=y
|
||||
# CONFIG_INPUT_EVBUG is not set
|
||||
|
||||
#
|
||||
# Input Device Drivers
|
||||
#
|
||||
# CONFIG_INPUT_KEYBOARD is not set
|
||||
# CONFIG_INPUT_MOUSE is not set
|
||||
CONFIG_INPUT_KEYBOARD=y
|
||||
CONFIG_KEYBOARD_ATKBD=y
|
||||
# CONFIG_KEYBOARD_SUNKBD is not set
|
||||
# CONFIG_KEYBOARD_LKKBD is not set
|
||||
# CONFIG_KEYBOARD_XTKBD is not set
|
||||
# CONFIG_KEYBOARD_NEWTON is not set
|
||||
CONFIG_INPUT_MOUSE=y
|
||||
CONFIG_MOUSE_PS2=y
|
||||
# CONFIG_MOUSE_SERIAL is not set
|
||||
# CONFIG_MOUSE_VSXXXAA is not set
|
||||
# CONFIG_INPUT_JOYSTICK is not set
|
||||
# CONFIG_INPUT_TOUCHSCREEN is not set
|
||||
# CONFIG_INPUT_MISC is not set
|
||||
|
@ -533,8 +447,9 @@ CONFIG_INPUT_EVBUG=y
|
|||
# Hardware I/O ports
|
||||
#
|
||||
CONFIG_SERIO=y
|
||||
CONFIG_SERIO_SERPORT=y
|
||||
# CONFIG_SERIO_LIBPS2 is not set
|
||||
# CONFIG_SERIO_SERPORT is not set
|
||||
CONFIG_SERIO_AMBAKMI=y
|
||||
CONFIG_SERIO_LIBPS2=y
|
||||
# CONFIG_SERIO_RAW is not set
|
||||
# CONFIG_GAMEPORT is not set
|
||||
|
||||
|
@ -549,21 +464,19 @@ CONFIG_HW_CONSOLE=y
|
|||
#
|
||||
# Serial drivers
|
||||
#
|
||||
CONFIG_SERIAL_8250=y
|
||||
CONFIG_SERIAL_8250_CONSOLE=y
|
||||
CONFIG_SERIAL_8250_NR_UARTS=2
|
||||
# CONFIG_SERIAL_8250_EXTENDED is not set
|
||||
# CONFIG_SERIAL_8250 is not set
|
||||
|
||||
#
|
||||
# Non-8250 serial port support
|
||||
#
|
||||
CONFIG_SERIAL_CLPS711X=y
|
||||
CONFIG_SERIAL_CLPS711X_CONSOLE=y
|
||||
# CONFIG_SERIAL_AMBA_PL010 is not set
|
||||
CONFIG_SERIAL_AMBA_PL011=y
|
||||
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
|
||||
CONFIG_SERIAL_CORE=y
|
||||
CONFIG_SERIAL_CORE_CONSOLE=y
|
||||
CONFIG_UNIX98_PTYS=y
|
||||
CONFIG_LEGACY_PTYS=y
|
||||
CONFIG_LEGACY_PTY_COUNT=256
|
||||
CONFIG_LEGACY_PTY_COUNT=16
|
||||
|
||||
#
|
||||
# IPMI
|
||||
|
@ -574,8 +487,8 @@ CONFIG_LEGACY_PTY_COUNT=256
|
|||
# Watchdog Cards
|
||||
#
|
||||
# CONFIG_WATCHDOG is not set
|
||||
CONFIG_NVRAM=y
|
||||
CONFIG_RTC=y
|
||||
# CONFIG_NVRAM is not set
|
||||
# CONFIG_RTC is not set
|
||||
# CONFIG_DTLK is not set
|
||||
# CONFIG_R3964 is not set
|
||||
|
||||
|
@ -596,9 +509,8 @@ CONFIG_RTC=y
|
|||
#
|
||||
# Hardware Monitoring support
|
||||
#
|
||||
CONFIG_HWMON=y
|
||||
# CONFIG_HWMON is not set
|
||||
# CONFIG_HWMON_VID is not set
|
||||
# CONFIG_HWMON_DEBUG_CHIP is not set
|
||||
|
||||
#
|
||||
# Misc devices
|
||||
|
@ -621,18 +533,72 @@ CONFIG_HWMON=y
|
|||
#
|
||||
# Graphics support
|
||||
#
|
||||
# CONFIG_FB is not set
|
||||
CONFIG_FB=y
|
||||
CONFIG_FB_CFB_FILLRECT=y
|
||||
CONFIG_FB_CFB_COPYAREA=y
|
||||
CONFIG_FB_CFB_IMAGEBLIT=y
|
||||
CONFIG_FB_SOFT_CURSOR=y
|
||||
# CONFIG_FB_MACMODES is not set
|
||||
# CONFIG_FB_MODE_HELPERS is not set
|
||||
# CONFIG_FB_TILEBLITTING is not set
|
||||
CONFIG_FB_ARMCLCD=y
|
||||
# CONFIG_FB_S1D13XXX is not set
|
||||
# CONFIG_FB_VIRTUAL is not set
|
||||
|
||||
#
|
||||
# Console display driver support
|
||||
#
|
||||
# CONFIG_VGA_CONSOLE is not set
|
||||
CONFIG_DUMMY_CONSOLE=y
|
||||
CONFIG_FRAMEBUFFER_CONSOLE=y
|
||||
# CONFIG_FONTS is not set
|
||||
CONFIG_FONT_8x8=y
|
||||
CONFIG_FONT_8x16=y
|
||||
|
||||
#
|
||||
# Logo configuration
|
||||
#
|
||||
CONFIG_LOGO=y
|
||||
# CONFIG_LOGO_LINUX_MONO is not set
|
||||
# CONFIG_LOGO_LINUX_VGA16 is not set
|
||||
CONFIG_LOGO_LINUX_CLUT224=y
|
||||
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
|
||||
|
||||
#
|
||||
# Sound
|
||||
#
|
||||
# CONFIG_SOUND is not set
|
||||
CONFIG_SOUND=y
|
||||
|
||||
#
|
||||
# Advanced Linux Sound Architecture
|
||||
#
|
||||
CONFIG_SND=y
|
||||
CONFIG_SND_TIMER=y
|
||||
CONFIG_SND_PCM=y
|
||||
# CONFIG_SND_SEQUENCER is not set
|
||||
CONFIG_SND_OSSEMUL=y
|
||||
CONFIG_SND_MIXER_OSS=y
|
||||
CONFIG_SND_PCM_OSS=y
|
||||
# CONFIG_SND_VERBOSE_PRINTK is not set
|
||||
# CONFIG_SND_DEBUG is not set
|
||||
|
||||
#
|
||||
# Generic devices
|
||||
#
|
||||
# CONFIG_SND_DUMMY is not set
|
||||
# CONFIG_SND_MTPAV is not set
|
||||
# CONFIG_SND_SERIAL_U16550 is not set
|
||||
# CONFIG_SND_MPU401 is not set
|
||||
|
||||
#
|
||||
# ALSA ARM devices
|
||||
#
|
||||
# CONFIG_SND_ARMAACI is not set
|
||||
|
||||
#
|
||||
# Open Sound System
|
||||
#
|
||||
# CONFIG_SOUND_PRIME is not set
|
||||
|
||||
#
|
||||
# USB support
|
||||
|
@ -654,32 +620,17 @@ CONFIG_USB_ARCH_HAS_HCD=y
|
|||
#
|
||||
# File systems
|
||||
#
|
||||
CONFIG_EXT2_FS=y
|
||||
CONFIG_EXT2_FS_XATTR=y
|
||||
# CONFIG_EXT2_FS_POSIX_ACL is not set
|
||||
# CONFIG_EXT2_FS_SECURITY is not set
|
||||
# CONFIG_EXT2_FS_XIP is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT3_FS_XATTR=y
|
||||
# CONFIG_EXT3_FS_POSIX_ACL is not set
|
||||
# CONFIG_EXT3_FS_SECURITY is not set
|
||||
CONFIG_JBD=y
|
||||
# CONFIG_JBD_DEBUG is not set
|
||||
CONFIG_FS_MBCACHE=y
|
||||
CONFIG_REISERFS_FS=m
|
||||
# CONFIG_REISERFS_CHECK is not set
|
||||
# CONFIG_REISERFS_PROC_INFO is not set
|
||||
# CONFIG_REISERFS_FS_XATTR is not set
|
||||
# CONFIG_EXT2_FS is not set
|
||||
# CONFIG_EXT3_FS is not set
|
||||
# CONFIG_JBD is not set
|
||||
# CONFIG_REISERFS_FS is not set
|
||||
# CONFIG_JFS_FS is not set
|
||||
CONFIG_FS_POSIX_ACL=y
|
||||
# CONFIG_FS_POSIX_ACL is not set
|
||||
# CONFIG_XFS_FS is not set
|
||||
# CONFIG_MINIX_FS is not set
|
||||
# CONFIG_ROMFS_FS is not set
|
||||
CONFIG_INOTIFY=y
|
||||
CONFIG_QUOTA=y
|
||||
# CONFIG_QFMT_V1 is not set
|
||||
# CONFIG_QFMT_V2 is not set
|
||||
CONFIG_QUOTACTL=y
|
||||
# CONFIG_QUOTA is not set
|
||||
CONFIG_DNOTIFY=y
|
||||
# CONFIG_AUTOFS_FS is not set
|
||||
# CONFIG_AUTOFS4_FS is not set
|
||||
|
@ -694,8 +645,11 @@ CONFIG_DNOTIFY=y
|
|||
#
|
||||
# DOS/FAT/NT Filesystems
|
||||
#
|
||||
CONFIG_FAT_FS=y
|
||||
# CONFIG_MSDOS_FS is not set
|
||||
# CONFIG_VFAT_FS is not set
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_FAT_DEFAULT_CODEPAGE=437
|
||||
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
|
||||
# CONFIG_NTFS_FS is not set
|
||||
|
||||
#
|
||||
|
@ -704,7 +658,6 @@ CONFIG_DNOTIFY=y
|
|||
CONFIG_PROC_FS=y
|
||||
CONFIG_SYSFS=y
|
||||
CONFIG_TMPFS=y
|
||||
# CONFIG_HUGETLBFS is not set
|
||||
# CONFIG_HUGETLB_PAGE is not set
|
||||
CONFIG_RAMFS=y
|
||||
# CONFIG_RELAYFS_FS is not set
|
||||
|
@ -712,22 +665,10 @@ CONFIG_RAMFS=y
|
|||
#
|
||||
# Miscellaneous filesystems
|
||||
#
|
||||
# CONFIG_ADFS_FS is not set
|
||||
# CONFIG_AFFS_FS is not set
|
||||
# CONFIG_HFS_FS is not set
|
||||
# CONFIG_HFSPLUS_FS is not set
|
||||
# CONFIG_BEFS_FS is not set
|
||||
# CONFIG_BFS_FS is not set
|
||||
# CONFIG_EFS_FS is not set
|
||||
# CONFIG_JFFS_FS is not set
|
||||
CONFIG_JFFS2_FS=m
|
||||
CONFIG_JFFS2_FS_DEBUG=0
|
||||
CONFIG_JFFS2_FS_WRITEBUFFER=y
|
||||
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
|
||||
CONFIG_JFFS2_ZLIB=y
|
||||
CONFIG_JFFS2_RTIME=y
|
||||
# CONFIG_JFFS2_RUBIN is not set
|
||||
CONFIG_CRAMFS=m
|
||||
# CONFIG_JFFS2_FS is not set
|
||||
CONFIG_CRAMFS=y
|
||||
# CONFIG_VXFS_FS is not set
|
||||
# CONFIG_HPFS_FS is not set
|
||||
# CONFIG_QNX4FS_FS is not set
|
||||
|
@ -740,32 +681,16 @@ CONFIG_CRAMFS=m
|
|||
CONFIG_NFS_FS=y
|
||||
CONFIG_NFS_V3=y
|
||||
# CONFIG_NFS_V3_ACL is not set
|
||||
CONFIG_NFS_V4=y
|
||||
# CONFIG_NFS_DIRECTIO is not set
|
||||
CONFIG_NFSD=y
|
||||
CONFIG_NFSD_V3=y
|
||||
# CONFIG_NFSD_V3_ACL is not set
|
||||
CONFIG_NFSD_V4=y
|
||||
CONFIG_NFSD_TCP=y
|
||||
# CONFIG_NFSD is not set
|
||||
CONFIG_ROOT_NFS=y
|
||||
CONFIG_LOCKD=y
|
||||
CONFIG_LOCKD_V4=y
|
||||
CONFIG_EXPORTFS=y
|
||||
CONFIG_NFS_COMMON=y
|
||||
CONFIG_SUNRPC=y
|
||||
CONFIG_SUNRPC_GSS=y
|
||||
CONFIG_RPCSEC_GSS_KRB5=y
|
||||
# CONFIG_RPCSEC_GSS_SPKM3 is not set
|
||||
CONFIG_SMB_FS=m
|
||||
# CONFIG_SMB_NLS_DEFAULT is not set
|
||||
CONFIG_CIFS=m
|
||||
# CONFIG_CIFS_STATS is not set
|
||||
# CONFIG_CIFS_XATTR is not set
|
||||
# CONFIG_CIFS_EXPERIMENTAL is not set
|
||||
# CONFIG_SMB_FS is not set
|
||||
# CONFIG_CIFS is not set
|
||||
# CONFIG_NCP_FS is not set
|
||||
# CONFIG_CODA_FS is not set
|
||||
# CONFIG_AFS_FS is not set
|
||||
# CONFIG_9P_FS is not set
|
||||
|
||||
#
|
||||
# Partition Types
|
||||
|
@ -802,7 +727,7 @@ CONFIG_NLS_CODEPAGE_437=y
|
|||
# CONFIG_NLS_CODEPAGE_1250 is not set
|
||||
# CONFIG_NLS_CODEPAGE_1251 is not set
|
||||
# CONFIG_NLS_ASCII is not set
|
||||
# CONFIG_NLS_ISO8859_1 is not set
|
||||
CONFIG_NLS_ISO8859_1=y
|
||||
# CONFIG_NLS_ISO8859_2 is not set
|
||||
# CONFIG_NLS_ISO8859_3 is not set
|
||||
# CONFIG_NLS_ISO8859_4 is not set
|
||||
|
@ -817,35 +742,27 @@ CONFIG_NLS_CODEPAGE_437=y
|
|||
# CONFIG_NLS_KOI8_U is not set
|
||||
# CONFIG_NLS_UTF8 is not set
|
||||
|
||||
#
|
||||
# Profiling support
|
||||
#
|
||||
# CONFIG_PROFILING is not set
|
||||
|
||||
#
|
||||
# Kernel hacking
|
||||
#
|
||||
CONFIG_PRINTK_TIME=y
|
||||
# CONFIG_PRINTK_TIME is not set
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
# CONFIG_MAGIC_SYSRQ is not set
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
CONFIG_LOG_BUF_SHIFT=14
|
||||
CONFIG_DETECT_SOFTLOCKUP=y
|
||||
# CONFIG_SCHEDSTATS is not set
|
||||
# CONFIG_DEBUG_SLAB is not set
|
||||
CONFIG_DEBUG_PREEMPT=y
|
||||
# CONFIG_DEBUG_SPINLOCK is not set
|
||||
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
|
||||
# CONFIG_DEBUG_KOBJECT is not set
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO=y
|
||||
CONFIG_DEBUG_BUGVERBOSE=y
|
||||
# CONFIG_DEBUG_INFO is not set
|
||||
# CONFIG_DEBUG_FS is not set
|
||||
CONFIG_FRAME_POINTER=y
|
||||
CONFIG_DEBUG_USER=y
|
||||
CONFIG_DEBUG_WAITQ=y
|
||||
# CONFIG_DEBUG_WAITQ is not set
|
||||
CONFIG_DEBUG_ERRORS=y
|
||||
CONFIG_DEBUG_LL=y
|
||||
# CONFIG_DEBUG_ICEDCC is not set
|
||||
# CONFIG_DEBUG_CLPS711X_UART2 is not set
|
||||
# CONFIG_DEBUG_LL is not set
|
||||
|
||||
#
|
||||
# Security options
|
||||
|
@ -856,31 +773,7 @@ CONFIG_DEBUG_LL=y
|
|||
#
|
||||
# Cryptographic options
|
||||
#
|
||||
CONFIG_CRYPTO=y
|
||||
# CONFIG_CRYPTO_HMAC is not set
|
||||
# CONFIG_CRYPTO_NULL is not set
|
||||
# CONFIG_CRYPTO_MD4 is not set
|
||||
CONFIG_CRYPTO_MD5=y
|
||||
# CONFIG_CRYPTO_SHA1 is not set
|
||||
# CONFIG_CRYPTO_SHA256 is not set
|
||||
# CONFIG_CRYPTO_SHA512 is not set
|
||||
# CONFIG_CRYPTO_WP512 is not set
|
||||
# CONFIG_CRYPTO_TGR192 is not set
|
||||
CONFIG_CRYPTO_DES=y
|
||||
# CONFIG_CRYPTO_BLOWFISH is not set
|
||||
# CONFIG_CRYPTO_TWOFISH is not set
|
||||
# CONFIG_CRYPTO_SERPENT is not set
|
||||
# CONFIG_CRYPTO_AES is not set
|
||||
# CONFIG_CRYPTO_CAST5 is not set
|
||||
# CONFIG_CRYPTO_CAST6 is not set
|
||||
# CONFIG_CRYPTO_TEA is not set
|
||||
# CONFIG_CRYPTO_ARC4 is not set
|
||||
# CONFIG_CRYPTO_KHAZAD is not set
|
||||
# CONFIG_CRYPTO_ANUBIS is not set
|
||||
# CONFIG_CRYPTO_DEFLATE is not set
|
||||
# CONFIG_CRYPTO_MICHAEL_MIC is not set
|
||||
# CONFIG_CRYPTO_CRC32C is not set
|
||||
# CONFIG_CRYPTO_TEST is not set
|
||||
# CONFIG_CRYPTO is not set
|
||||
|
||||
#
|
||||
# Hardware crypto devices
|
||||
|
@ -893,5 +786,4 @@ CONFIG_CRYPTO_DES=y
|
|||
# CONFIG_CRC16 is not set
|
||||
CONFIG_CRC32=y
|
||||
# CONFIG_LIBCRC32C is not set
|
||||
CONFIG_ZLIB_INFLATE=m
|
||||
CONFIG_ZLIB_DEFLATE=m
|
||||
CONFIG_ZLIB_INFLATE=y
|
|
@ -9,6 +9,7 @@
|
|||
*/
|
||||
#include <linux/module.h>
|
||||
#include <linux/string.h>
|
||||
#include <linux/cryptohash.h>
|
||||
#include <linux/delay.h>
|
||||
#include <linux/in6.h>
|
||||
#include <linux/syscalls.h>
|
||||
|
@ -126,6 +127,9 @@ EXPORT_SYMBOL(__put_user_2);
|
|||
EXPORT_SYMBOL(__put_user_4);
|
||||
EXPORT_SYMBOL(__put_user_8);
|
||||
|
||||
/* crypto hash */
|
||||
EXPORT_SYMBOL(sha_transform);
|
||||
|
||||
/* gcc lib functions */
|
||||
EXPORT_SYMBOL(__ashldi3);
|
||||
EXPORT_SYMBOL(__ashrdi3);
|
||||
|
|
|
@ -47,6 +47,13 @@
|
|||
movne r0, sp
|
||||
adrne lr, 1b
|
||||
bne do_IPI
|
||||
|
||||
#ifdef CONFIG_LOCAL_TIMERS
|
||||
test_for_ltirq r0, r6, r5, lr
|
||||
movne r0, sp
|
||||
adrne lr, 1b
|
||||
bne do_local_timer
|
||||
#endif
|
||||
#endif
|
||||
|
||||
.endm
|
||||
|
@ -785,7 +792,7 @@ __kuser_helper_end:
|
|||
* SP points to a minimal amount of processor-private memory, the address
|
||||
* of which is copied into r0 for the mode specific abort handler.
|
||||
*/
|
||||
.macro vector_stub, name, correction=0
|
||||
.macro vector_stub, name, mode, correction=0
|
||||
.align 5
|
||||
|
||||
vector_\name:
|
||||
|
@ -805,15 +812,14 @@ vector_\name:
|
|||
@ Prepare for SVC32 mode. IRQs remain disabled.
|
||||
@
|
||||
mrs r0, cpsr
|
||||
bic r0, r0, #MODE_MASK
|
||||
orr r0, r0, #SVC_MODE
|
||||
eor r0, r0, #(\mode ^ SVC_MODE)
|
||||
msr spsr_cxsf, r0
|
||||
|
||||
@
|
||||
@ the branch table must immediately follow this code
|
||||
@
|
||||
mov r0, sp
|
||||
and lr, lr, #0x0f
|
||||
mov r0, sp
|
||||
ldr lr, [pc, lr, lsl #2]
|
||||
movs pc, lr @ branch to handler in SVC mode
|
||||
.endm
|
||||
|
@ -823,7 +829,7 @@ __stubs_start:
|
|||
/*
|
||||
* Interrupt dispatcher
|
||||
*/
|
||||
vector_stub irq, 4
|
||||
vector_stub irq, IRQ_MODE, 4
|
||||
|
||||
.long __irq_usr @ 0 (USR_26 / USR_32)
|
||||
.long __irq_invalid @ 1 (FIQ_26 / FIQ_32)
|
||||
|
@ -846,7 +852,7 @@ __stubs_start:
|
|||
* Data abort dispatcher
|
||||
* Enter in ABT mode, spsr = USR CPSR, lr = USR PC
|
||||
*/
|
||||
vector_stub dabt, 8
|
||||
vector_stub dabt, ABT_MODE, 8
|
||||
|
||||
.long __dabt_usr @ 0 (USR_26 / USR_32)
|
||||
.long __dabt_invalid @ 1 (FIQ_26 / FIQ_32)
|
||||
|
@ -869,7 +875,7 @@ __stubs_start:
|
|||
* Prefetch abort dispatcher
|
||||
* Enter in ABT mode, spsr = USR CPSR, lr = USR PC
|
||||
*/
|
||||
vector_stub pabt, 4
|
||||
vector_stub pabt, ABT_MODE, 4
|
||||
|
||||
.long __pabt_usr @ 0 (USR_26 / USR_32)
|
||||
.long __pabt_invalid @ 1 (FIQ_26 / FIQ_32)
|
||||
|
@ -892,7 +898,7 @@ __stubs_start:
|
|||
* Undef instr entry dispatcher
|
||||
* Enter in UND mode, spsr = SVC/USR CPSR, lr = SVC/USR PC
|
||||
*/
|
||||
vector_stub und
|
||||
vector_stub und, UND_MODE
|
||||
|
||||
.long __und_usr @ 0 (USR_26 / USR_32)
|
||||
.long __und_invalid @ 1 (FIQ_26 / FIQ_32)
|
||||
|
|
|
@ -264,6 +264,7 @@ unlock:
|
|||
#endif
|
||||
#ifdef CONFIG_SMP
|
||||
show_ipi_list(p);
|
||||
show_local_irqs(p);
|
||||
#endif
|
||||
seq_printf(p, "Err: %10lu\n", irq_err_count);
|
||||
}
|
||||
|
@ -995,7 +996,7 @@ void __init init_irq_proc(void)
|
|||
struct proc_dir_entry *dir;
|
||||
int irq;
|
||||
|
||||
dir = proc_mkdir("irq", 0);
|
||||
dir = proc_mkdir("irq", NULL);
|
||||
if (!dir)
|
||||
return;
|
||||
|
||||
|
@ -1050,3 +1051,34 @@ static int __init noirqdebug_setup(char *str)
|
|||
}
|
||||
|
||||
__setup("noirqdebug", noirqdebug_setup);
|
||||
|
||||
#ifdef CONFIG_HOTPLUG_CPU
|
||||
/*
|
||||
* The CPU has been marked offline. Migrate IRQs off this CPU. If
|
||||
* the affinity settings do not allow other CPUs, force them onto any
|
||||
* available CPU.
|
||||
*/
|
||||
void migrate_irqs(void)
|
||||
{
|
||||
unsigned int i, cpu = smp_processor_id();
|
||||
|
||||
for (i = 0; i < NR_IRQS; i++) {
|
||||
struct irqdesc *desc = irq_desc + i;
|
||||
|
||||
if (desc->cpu == cpu) {
|
||||
unsigned int newcpu = any_online_cpu(desc->affinity);
|
||||
|
||||
if (newcpu == NR_CPUS) {
|
||||
if (printk_ratelimit())
|
||||
printk(KERN_INFO "IRQ%u no longer affine to CPU%u\n",
|
||||
i, cpu);
|
||||
|
||||
cpus_setall(desc->affinity);
|
||||
newcpu = any_online_cpu(desc->affinity);
|
||||
}
|
||||
|
||||
route_irq(desc, i, newcpu);
|
||||
}
|
||||
}
|
||||
}
|
||||
#endif /* CONFIG_HOTPLUG_CPU */
|
||||
|
|
|
@ -26,6 +26,7 @@
|
|||
#include <linux/interrupt.h>
|
||||
#include <linux/kallsyms.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/cpu.h>
|
||||
|
||||
#include <asm/system.h>
|
||||
#include <asm/io.h>
|
||||
|
@ -85,12 +86,16 @@ EXPORT_SYMBOL(pm_power_off);
|
|||
*/
|
||||
void default_idle(void)
|
||||
{
|
||||
local_irq_disable();
|
||||
if (!need_resched() && !hlt_counter) {
|
||||
timer_dyn_reprogram();
|
||||
arch_idle();
|
||||
if (hlt_counter)
|
||||
cpu_relax();
|
||||
else {
|
||||
local_irq_disable();
|
||||
if (!need_resched()) {
|
||||
timer_dyn_reprogram();
|
||||
arch_idle();
|
||||
}
|
||||
local_irq_enable();
|
||||
}
|
||||
local_irq_enable();
|
||||
}
|
||||
|
||||
/*
|
||||
|
@ -105,15 +110,23 @@ void cpu_idle(void)
|
|||
/* endless idle loop with no priority at all */
|
||||
while (1) {
|
||||
void (*idle)(void) = pm_idle;
|
||||
|
||||
#ifdef CONFIG_HOTPLUG_CPU
|
||||
if (cpu_is_offline(smp_processor_id())) {
|
||||
leds_event(led_idle_start);
|
||||
cpu_die();
|
||||
}
|
||||
#endif
|
||||
|
||||
if (!idle)
|
||||
idle = default_idle;
|
||||
preempt_disable();
|
||||
leds_event(led_idle_start);
|
||||
while (!need_resched())
|
||||
idle();
|
||||
leds_event(led_idle_end);
|
||||
preempt_enable();
|
||||
preempt_enable_no_resched();
|
||||
schedule();
|
||||
preempt_disable();
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -346,7 +359,7 @@ copy_thread(int nr, unsigned long clone_flags, unsigned long stack_start,
|
|||
struct thread_info *thread = p->thread_info;
|
||||
struct pt_regs *childregs;
|
||||
|
||||
childregs = ((struct pt_regs *)((unsigned long)thread + THREAD_START_SP)) - 1;
|
||||
childregs = (void *)thread + THREAD_START_SP - sizeof(*regs);
|
||||
*childregs = *regs;
|
||||
childregs->ARM_r0 = 0;
|
||||
childregs->ARM_sp = stack_start;
|
||||
|
|
|
@ -648,7 +648,7 @@ static int ptrace_setwmmxregs(struct task_struct *tsk, void __user *ufp)
|
|||
|
||||
#endif
|
||||
|
||||
static int do_ptrace(int request, struct task_struct *child, long addr, long data)
|
||||
long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
||||
{
|
||||
unsigned long tmp;
|
||||
int ret;
|
||||
|
@ -782,53 +782,6 @@ static int do_ptrace(int request, struct task_struct *child, long addr, long dat
|
|||
return ret;
|
||||
}
|
||||
|
||||
asmlinkage long sys_ptrace(long request, long pid, long addr, long data)
|
||||
{
|
||||
struct task_struct *child;
|
||||
int ret;
|
||||
|
||||
lock_kernel();
|
||||
ret = -EPERM;
|
||||
if (request == PTRACE_TRACEME) {
|
||||
/* are we already being traced? */
|
||||
if (current->ptrace & PT_PTRACED)
|
||||
goto out;
|
||||
ret = security_ptrace(current->parent, current);
|
||||
if (ret)
|
||||
goto out;
|
||||
/* set the ptrace bit in the process flags. */
|
||||
current->ptrace |= PT_PTRACED;
|
||||
ret = 0;
|
||||
goto out;
|
||||
}
|
||||
ret = -ESRCH;
|
||||
read_lock(&tasklist_lock);
|
||||
child = find_task_by_pid(pid);
|
||||
if (child)
|
||||
get_task_struct(child);
|
||||
read_unlock(&tasklist_lock);
|
||||
if (!child)
|
||||
goto out;
|
||||
|
||||
ret = -EPERM;
|
||||
if (pid == 1) /* you may not mess with init */
|
||||
goto out_tsk;
|
||||
|
||||
if (request == PTRACE_ATTACH) {
|
||||
ret = ptrace_attach(child);
|
||||
goto out_tsk;
|
||||
}
|
||||
ret = ptrace_check_attach(child, request == PTRACE_KILL);
|
||||
if (ret == 0)
|
||||
ret = do_ptrace(request, child, addr, data);
|
||||
|
||||
out_tsk:
|
||||
put_task_struct(child);
|
||||
out:
|
||||
unlock_kernel();
|
||||
return ret;
|
||||
}
|
||||
|
||||
asmlinkage void syscall_trace(int why, struct pt_regs *regs)
|
||||
{
|
||||
unsigned long ip;
|
||||
|
|
|
@ -338,7 +338,8 @@ void cpu_init(void)
|
|||
BUG();
|
||||
}
|
||||
|
||||
dump_cpu_info(cpu);
|
||||
if (system_state == SYSTEM_BOOTING)
|
||||
dump_cpu_info(cpu);
|
||||
|
||||
/*
|
||||
* setup stacks for re-entrant exception handlers
|
||||
|
@ -838,7 +839,12 @@ static int c_show(struct seq_file *m, void *v)
|
|||
|
||||
#if defined(CONFIG_SMP)
|
||||
for_each_online_cpu(i) {
|
||||
seq_printf(m, "Processor\t: %d\n", i);
|
||||
/*
|
||||
* glibc reads /proc/cpuinfo to determine the number of
|
||||
* online processors, looking for lines beginning with
|
||||
* "processor". Give glibc what it expects.
|
||||
*/
|
||||
seq_printf(m, "processor\t: %d\n", i);
|
||||
seq_printf(m, "BogoMIPS\t: %lu.%02lu\n\n",
|
||||
per_cpu(cpu_data, i).loops_per_jiffy / (500000UL/HZ),
|
||||
(per_cpu(cpu_data, i).loops_per_jiffy / (5000UL/HZ)) % 100);
|
||||
|
|
|
@ -80,19 +80,23 @@ static DEFINE_SPINLOCK(smp_call_function_lock);
|
|||
|
||||
int __cpuinit __cpu_up(unsigned int cpu)
|
||||
{
|
||||
struct task_struct *idle;
|
||||
struct cpuinfo_arm *ci = &per_cpu(cpu_data, cpu);
|
||||
struct task_struct *idle = ci->idle;
|
||||
pgd_t *pgd;
|
||||
pmd_t *pmd;
|
||||
int ret;
|
||||
|
||||
/*
|
||||
* Spawn a new process manually. Grab a pointer to
|
||||
* its task struct so we can mess with it
|
||||
* Spawn a new process manually, if not already done.
|
||||
* Grab a pointer to its task struct so we can mess with it
|
||||
*/
|
||||
idle = fork_idle(cpu);
|
||||
if (IS_ERR(idle)) {
|
||||
printk(KERN_ERR "CPU%u: fork() failed\n", cpu);
|
||||
return PTR_ERR(idle);
|
||||
if (!idle) {
|
||||
idle = fork_idle(cpu);
|
||||
if (IS_ERR(idle)) {
|
||||
printk(KERN_ERR "CPU%u: fork() failed\n", cpu);
|
||||
return PTR_ERR(idle);
|
||||
}
|
||||
ci->idle = idle;
|
||||
}
|
||||
|
||||
/*
|
||||
|
@ -138,7 +142,7 @@ int __cpuinit __cpu_up(unsigned int cpu)
|
|||
ret = -EIO;
|
||||
}
|
||||
|
||||
secondary_data.stack = 0;
|
||||
secondary_data.stack = NULL;
|
||||
secondary_data.pgdir = 0;
|
||||
|
||||
*pmd_offset(pgd, PHYS_OFFSET) = __pmd(0);
|
||||
|
@ -155,6 +159,96 @@ int __cpuinit __cpu_up(unsigned int cpu)
|
|||
return ret;
|
||||
}
|
||||
|
||||
#ifdef CONFIG_HOTPLUG_CPU
|
||||
/*
|
||||
* __cpu_disable runs on the processor to be shutdown.
|
||||
*/
|
||||
int __cpuexit __cpu_disable(void)
|
||||
{
|
||||
unsigned int cpu = smp_processor_id();
|
||||
struct task_struct *p;
|
||||
int ret;
|
||||
|
||||
ret = mach_cpu_disable(cpu);
|
||||
if (ret)
|
||||
return ret;
|
||||
|
||||
/*
|
||||
* Take this CPU offline. Once we clear this, we can't return,
|
||||
* and we must not schedule until we're ready to give up the cpu.
|
||||
*/
|
||||
cpu_clear(cpu, cpu_online_map);
|
||||
|
||||
/*
|
||||
* OK - migrate IRQs away from this CPU
|
||||
*/
|
||||
migrate_irqs();
|
||||
|
||||
/*
|
||||
* Stop the local timer for this CPU.
|
||||
*/
|
||||
local_timer_stop(cpu);
|
||||
|
||||
/*
|
||||
* Flush user cache and TLB mappings, and then remove this CPU
|
||||
* from the vm mask set of all processes.
|
||||
*/
|
||||
flush_cache_all();
|
||||
local_flush_tlb_all();
|
||||
|
||||
read_lock(&tasklist_lock);
|
||||
for_each_process(p) {
|
||||
if (p->mm)
|
||||
cpu_clear(cpu, p->mm->cpu_vm_mask);
|
||||
}
|
||||
read_unlock(&tasklist_lock);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* called on the thread which is asking for a CPU to be shutdown -
|
||||
* waits until shutdown has completed, or it is timed out.
|
||||
*/
|
||||
void __cpuexit __cpu_die(unsigned int cpu)
|
||||
{
|
||||
if (!platform_cpu_kill(cpu))
|
||||
printk("CPU%u: unable to kill\n", cpu);
|
||||
}
|
||||
|
||||
/*
|
||||
* Called from the idle thread for the CPU which has been shutdown.
|
||||
*
|
||||
* Note that we disable IRQs here, but do not re-enable them
|
||||
* before returning to the caller. This is also the behaviour
|
||||
* of the other hotplug-cpu capable cores, so presumably coming
|
||||
* out of idle fixes this.
|
||||
*/
|
||||
void __cpuexit cpu_die(void)
|
||||
{
|
||||
unsigned int cpu = smp_processor_id();
|
||||
|
||||
local_irq_disable();
|
||||
idle_task_exit();
|
||||
|
||||
/*
|
||||
* actual CPU shutdown procedure is at least platform (if not
|
||||
* CPU) specific
|
||||
*/
|
||||
platform_cpu_die(cpu);
|
||||
|
||||
/*
|
||||
* Do not return to the idle loop - jump back to the secondary
|
||||
* cpu initialisation. There's some initialisation which needs
|
||||
* to be repeated to undo the effects of taking the CPU offline.
|
||||
*/
|
||||
__asm__("mov sp, %0\n"
|
||||
" b secondary_start_kernel"
|
||||
:
|
||||
: "r" ((void *)current->thread_info + THREAD_SIZE - 8));
|
||||
}
|
||||
#endif /* CONFIG_HOTPLUG_CPU */
|
||||
|
||||
/*
|
||||
* This is the secondary CPU boot entry. We're using this CPUs
|
||||
* idle thread stack, but a set of temporary page tables.
|
||||
|
@ -162,7 +256,9 @@ int __cpuinit __cpu_up(unsigned int cpu)
|
|||
asmlinkage void __cpuinit secondary_start_kernel(void)
|
||||
{
|
||||
struct mm_struct *mm = &init_mm;
|
||||
unsigned int cpu = smp_processor_id();
|
||||
unsigned int cpu;
|
||||
|
||||
cpu = smp_processor_id();
|
||||
|
||||
printk("CPU%u: Booted secondary processor\n", cpu);
|
||||
|
||||
|
@ -179,6 +275,7 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
|
|||
local_flush_tlb_all();
|
||||
|
||||
cpu_init();
|
||||
preempt_disable();
|
||||
|
||||
/*
|
||||
* Give the platform a chance to do its own initialisation.
|
||||
|
@ -200,6 +297,11 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
|
|||
*/
|
||||
cpu_set(cpu, cpu_online_map);
|
||||
|
||||
/*
|
||||
* Setup local timer for this CPU.
|
||||
*/
|
||||
local_timer_setup(cpu);
|
||||
|
||||
/*
|
||||
* OK, it's off to the idle thread for us
|
||||
*/
|
||||
|
@ -236,6 +338,8 @@ void __init smp_prepare_boot_cpu(void)
|
|||
{
|
||||
unsigned int cpu = smp_processor_id();
|
||||
|
||||
per_cpu(cpu_data, cpu).idle = current;
|
||||
|
||||
cpu_set(cpu, cpu_possible_map);
|
||||
cpu_set(cpu, cpu_present_map);
|
||||
cpu_set(cpu, cpu_online_map);
|
||||
|
@ -268,8 +372,8 @@ static void send_ipi_message(cpumask_t callmap, enum ipi_msg_type msg)
|
|||
* You must not call this function with disabled interrupts, from a
|
||||
* hardware interrupt handler, nor from a bottom half handler.
|
||||
*/
|
||||
int smp_call_function_on_cpu(void (*func)(void *info), void *info, int retry,
|
||||
int wait, cpumask_t callmap)
|
||||
static int smp_call_function_on_cpu(void (*func)(void *info), void *info,
|
||||
int retry, int wait, cpumask_t callmap)
|
||||
{
|
||||
struct smp_call_struct data;
|
||||
unsigned long timeout;
|
||||
|
@ -309,8 +413,8 @@ int smp_call_function_on_cpu(void (*func)(void *info), void *info, int retry,
|
|||
printk(KERN_CRIT
|
||||
"CPU%u: smp_call_function timeout for %p(%p)\n"
|
||||
" callmap %lx pending %lx, %swait\n",
|
||||
smp_processor_id(), func, info, callmap, data.pending,
|
||||
wait ? "" : "no ");
|
||||
smp_processor_id(), func, info, *cpus_addr(callmap),
|
||||
*cpus_addr(data.pending), wait ? "" : "no ");
|
||||
|
||||
/*
|
||||
* TRACE
|
||||
|
@ -363,6 +467,18 @@ void show_ipi_list(struct seq_file *p)
|
|||
seq_putc(p, '\n');
|
||||
}
|
||||
|
||||
void show_local_irqs(struct seq_file *p)
|
||||
{
|
||||
unsigned int cpu;
|
||||
|
||||
seq_printf(p, "LOC: ");
|
||||
|
||||
for_each_present_cpu(cpu)
|
||||
seq_printf(p, "%10u ", irq_stat[cpu].local_timer_irqs);
|
||||
|
||||
seq_putc(p, '\n');
|
||||
}
|
||||
|
||||
static void ipi_timer(struct pt_regs *regs)
|
||||
{
|
||||
int user = user_mode(regs);
|
||||
|
@ -373,6 +489,18 @@ static void ipi_timer(struct pt_regs *regs)
|
|||
irq_exit();
|
||||
}
|
||||
|
||||
#ifdef CONFIG_LOCAL_TIMERS
|
||||
asmlinkage void do_local_timer(struct pt_regs *regs)
|
||||
{
|
||||
int cpu = smp_processor_id();
|
||||
|
||||
if (local_timer_ack()) {
|
||||
irq_stat[cpu].local_timer_irqs++;
|
||||
ipi_timer(regs);
|
||||
}
|
||||
}
|
||||
#endif
|
||||
|
||||
/*
|
||||
* ipi_call_function - handle IPI from smp_call_function()
|
||||
*
|
||||
|
@ -424,7 +552,7 @@ static void ipi_cpu_stop(unsigned int cpu)
|
|||
*
|
||||
* Bit 0 - Inter-processor function call
|
||||
*/
|
||||
void do_IPI(struct pt_regs *regs)
|
||||
asmlinkage void do_IPI(struct pt_regs *regs)
|
||||
{
|
||||
unsigned int cpu = smp_processor_id();
|
||||
struct ipi_data *ipi = &per_cpu(ipi_data, cpu);
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
#include <linux/config.h>
|
||||
|
||||
#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_MPCORE)
|
||||
#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
|
||||
.macro bitop, instr
|
||||
mov r2, #1
|
||||
and r3, r0, #7 @ Get bit offset
|
||||
|
@ -34,7 +34,7 @@
|
|||
and r2, r0, #7
|
||||
mov r3, #1
|
||||
mov r3, r3, lsl r2
|
||||
save_and_disable_irqs ip, r2
|
||||
save_and_disable_irqs ip
|
||||
ldrb r2, [r1, r0, lsr #3]
|
||||
\instr r2, r2, r3
|
||||
strb r2, [r1, r0, lsr #3]
|
||||
|
@ -54,7 +54,7 @@
|
|||
add r1, r1, r0, lsr #3
|
||||
and r3, r0, #7
|
||||
mov r0, #1
|
||||
save_and_disable_irqs ip, r2
|
||||
save_and_disable_irqs ip
|
||||
ldrb r2, [r1]
|
||||
tst r2, r0, lsl r3
|
||||
\instr r2, r2, r0, lsl r3
|
||||
|
|
|
@ -43,8 +43,6 @@ ENTRY(__arch_copy_to_user)
|
|||
stmfd sp!, {r2, r4 - r7, lr}
|
||||
cmp r2, #4
|
||||
blt .c2u_not_enough
|
||||
PLD( pld [r1, #0] )
|
||||
PLD( pld [r0, #0] )
|
||||
ands ip, r0, #3
|
||||
bne .c2u_dest_not_aligned
|
||||
.c2u_dest_aligned:
|
||||
|
@ -73,25 +71,13 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #32
|
||||
blt .c2u_0rem8lp
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
PLD( subs ip, ip, #64 )
|
||||
PLD( blt .c2u_0cpynopld )
|
||||
PLD( pld [r1, #60] )
|
||||
PLD( pld [r0, #60] )
|
||||
|
||||
.c2u_0cpy8lp:
|
||||
PLD( pld [r1, #92] )
|
||||
PLD( pld [r0, #92] )
|
||||
.c2u_0cpynopld: ldmia r1!, {r3 - r6}
|
||||
.c2u_0cpy8lp: ldmia r1!, {r3 - r6}
|
||||
stmia r0!, {r3 - r6} @ Shouldnt fault
|
||||
ldmia r1!, {r3 - r6}
|
||||
subs ip, ip, #32
|
||||
stmia r0!, {r3 - r6} @ Shouldnt fault
|
||||
bpl .c2u_0cpy8lp
|
||||
PLD( cmn ip, #64 )
|
||||
PLD( bge .c2u_0cpynopld )
|
||||
PLD( add ip, ip, #64 )
|
||||
|
||||
.c2u_0rem8lp: cmn ip, #16
|
||||
ldmgeia r1!, {r3 - r6}
|
||||
|
@ -143,17 +129,8 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .c2u_1rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .c2u_1cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.c2u_1cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.c2u_1cpynopld: mov r3, r7, pull #8
|
||||
.c2u_1cpy8lp: mov r3, r7, pull #8
|
||||
ldmia r1!, {r4 - r7}
|
||||
subs ip, ip, #16
|
||||
orr r3, r3, r4, push #24
|
||||
|
@ -165,9 +142,6 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
orr r6, r6, r7, push #24
|
||||
stmia r0!, {r3 - r6} @ Shouldnt fault
|
||||
bpl .c2u_1cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .c2u_1cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.c2u_1rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #8
|
||||
|
@ -210,17 +184,8 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .c2u_2rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .c2u_2cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.c2u_2cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.c2u_2cpynopld: mov r3, r7, pull #16
|
||||
.c2u_2cpy8lp: mov r3, r7, pull #16
|
||||
ldmia r1!, {r4 - r7}
|
||||
subs ip, ip, #16
|
||||
orr r3, r3, r4, push #16
|
||||
|
@ -232,9 +197,6 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
orr r6, r6, r7, push #16
|
||||
stmia r0!, {r3 - r6} @ Shouldnt fault
|
||||
bpl .c2u_2cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .c2u_2cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.c2u_2rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #16
|
||||
|
@ -277,17 +239,8 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .c2u_3rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .c2u_3cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.c2u_3cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.c2u_3cpynopld: mov r3, r7, pull #24
|
||||
.c2u_3cpy8lp: mov r3, r7, pull #24
|
||||
ldmia r1!, {r4 - r7}
|
||||
subs ip, ip, #16
|
||||
orr r3, r3, r4, push #8
|
||||
|
@ -299,9 +252,6 @@ USER( strt r3, [r0], #4) @ May fault
|
|||
orr r6, r6, r7, push #8
|
||||
stmia r0!, {r3 - r6} @ Shouldnt fault
|
||||
bpl .c2u_3cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .c2u_3cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.c2u_3rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #24
|
||||
|
@ -356,8 +306,6 @@ ENTRY(__arch_copy_from_user)
|
|||
stmfd sp!, {r0, r2, r4 - r7, lr}
|
||||
cmp r2, #4
|
||||
blt .cfu_not_enough
|
||||
PLD( pld [r1, #0] )
|
||||
PLD( pld [r0, #0] )
|
||||
ands ip, r0, #3
|
||||
bne .cfu_dest_not_aligned
|
||||
.cfu_dest_aligned:
|
||||
|
@ -385,25 +333,13 @@ USER( ldrt r3, [r1], #4)
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #32
|
||||
blt .cfu_0rem8lp
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
PLD( subs ip, ip, #64 )
|
||||
PLD( blt .cfu_0cpynopld )
|
||||
PLD( pld [r1, #60] )
|
||||
PLD( pld [r0, #60] )
|
||||
|
||||
.cfu_0cpy8lp:
|
||||
PLD( pld [r1, #92] )
|
||||
PLD( pld [r0, #92] )
|
||||
.cfu_0cpynopld: ldmia r1!, {r3 - r6} @ Shouldnt fault
|
||||
.cfu_0cpy8lp: ldmia r1!, {r3 - r6} @ Shouldnt fault
|
||||
stmia r0!, {r3 - r6}
|
||||
ldmia r1!, {r3 - r6} @ Shouldnt fault
|
||||
subs ip, ip, #32
|
||||
stmia r0!, {r3 - r6}
|
||||
bpl .cfu_0cpy8lp
|
||||
PLD( cmn ip, #64 )
|
||||
PLD( bge .cfu_0cpynopld )
|
||||
PLD( add ip, ip, #64 )
|
||||
|
||||
.cfu_0rem8lp: cmn ip, #16
|
||||
ldmgeia r1!, {r3 - r6} @ Shouldnt fault
|
||||
|
@ -456,17 +392,8 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .cfu_1rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .cfu_1cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.cfu_1cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.cfu_1cpynopld: mov r3, r7, pull #8
|
||||
.cfu_1cpy8lp: mov r3, r7, pull #8
|
||||
ldmia r1!, {r4 - r7} @ Shouldnt fault
|
||||
subs ip, ip, #16
|
||||
orr r3, r3, r4, push #24
|
||||
|
@ -478,9 +405,6 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
orr r6, r6, r7, push #24
|
||||
stmia r0!, {r3 - r6}
|
||||
bpl .cfu_1cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .cfu_1cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.cfu_1rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #8
|
||||
|
@ -523,17 +447,8 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .cfu_2rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .cfu_2cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.cfu_2cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.cfu_2cpynopld: mov r3, r7, pull #16
|
||||
.cfu_2cpy8lp: mov r3, r7, pull #16
|
||||
ldmia r1!, {r4 - r7} @ Shouldnt fault
|
||||
subs ip, ip, #16
|
||||
orr r3, r3, r4, push #16
|
||||
|
@ -545,9 +460,6 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
orr r6, r6, r7, push #16
|
||||
stmia r0!, {r3 - r6}
|
||||
bpl .cfu_2cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .cfu_2cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.cfu_2rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #16
|
||||
|
@ -590,17 +502,8 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
sub r2, r2, ip
|
||||
subs ip, ip, #16
|
||||
blt .cfu_3rem8lp
|
||||
PLD( pld [r1, #12] )
|
||||
PLD( pld [r0, #12] )
|
||||
PLD( subs ip, ip, #32 )
|
||||
PLD( blt .cfu_3cpynopld )
|
||||
PLD( pld [r1, #28] )
|
||||
PLD( pld [r0, #28] )
|
||||
|
||||
.cfu_3cpy8lp:
|
||||
PLD( pld [r1, #44] )
|
||||
PLD( pld [r0, #44] )
|
||||
.cfu_3cpynopld: mov r3, r7, pull #24
|
||||
.cfu_3cpy8lp: mov r3, r7, pull #24
|
||||
ldmia r1!, {r4 - r7} @ Shouldnt fault
|
||||
orr r3, r3, r4, push #8
|
||||
mov r4, r4, pull #24
|
||||
|
@ -612,9 +515,6 @@ USER( ldrt r7, [r1], #4) @ May fault
|
|||
stmia r0!, {r3 - r6}
|
||||
subs ip, ip, #16
|
||||
bpl .cfu_3cpy8lp
|
||||
PLD( cmn ip, #32 )
|
||||
PLD( bge .cfu_3cpynopld )
|
||||
PLD( add ip, ip, #32 )
|
||||
|
||||
.cfu_3rem8lp: tst ip, #8
|
||||
movne r3, r7, pull #24
|
||||
|
|
|
@ -14,6 +14,7 @@
|
|||
#include <linux/list.h>
|
||||
#include <linux/errno.h>
|
||||
#include <linux/err.h>
|
||||
#include <linux/string.h>
|
||||
|
||||
#include <asm/semaphore.h>
|
||||
#include <asm/hardware/clock.h>
|
||||
|
|
|
@ -69,17 +69,6 @@ config EP72XX_ROM_BOOT
|
|||
|
||||
You almost surely want to say N here.
|
||||
|
||||
config MACH_MP1000
|
||||
bool "MACH_MP1000"
|
||||
help
|
||||
Say Y if you intend to run the kernel on the Comdial MP1000 platform.
|
||||
|
||||
config MP1000_90MHZ
|
||||
bool "MP1000_90MHZ"
|
||||
depends on MACH_MP1000
|
||||
help
|
||||
Say Y if you have the MP1000 configured to be set at 90MHZ rather than 74MHZ
|
||||
|
||||
endmenu
|
||||
|
||||
endif
|
||||
|
|
|
@ -15,7 +15,6 @@ obj-$(CONFIG_ARCH_CDB89712) += cdb89712.o
|
|||
obj-$(CONFIG_ARCH_CLEP7312) += clep7312.o
|
||||
obj-$(CONFIG_ARCH_EDB7211) += edb7211-arch.o edb7211-mm.o
|
||||
obj-$(CONFIG_ARCH_FORTUNET) += fortunet.o
|
||||
obj-$(CONFIG_MACH_MP1000) += mp1000-mach.o mp1000-mm.o mp1000-seprom.o
|
||||
obj-$(CONFIG_ARCH_P720T) += p720t.o
|
||||
leds-$(CONFIG_ARCH_P720T) += p720t-leds.o
|
||||
obj-$(CONFIG_LEDS) += $(leds-y)
|
||||
|
|
|
@ -55,22 +55,22 @@ static struct map_desc edb7211_io_desc[] __initdata = {
|
|||
.virtual = EP7211_VIRT_EXTKBD,
|
||||
.pfn = __phys_to_pfn(EP7211_PHYS_EXTKBD),
|
||||
.length = SZ_1M,
|
||||
.type - MT_DEVICE
|
||||
.type = MT_DEVICE,
|
||||
}, { /* and CS8900A Ethernet chip */
|
||||
.virtual = EP7211_VIRT_CS8900A,
|
||||
.pfn = __phys_to_pfn(EP7211_PHYS_CS8900A),
|
||||
.length = SZ_1M,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_DEVICE,
|
||||
}, { /* flash banks */
|
||||
.virtual = EP7211_VIRT_FLASH1,
|
||||
.pfn = __phys_to_pfn(EP7211_PHYS_FLASH1),
|
||||
.length = SZ_8M,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_DEVICE,
|
||||
}, {
|
||||
.virtual = EP7211_VIRT_FLASH2,
|
||||
.pfn = __phys_to_pfn(EP7211_PHYS_FLASH2),
|
||||
.length = SZ_8M,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_DEVICE,
|
||||
}
|
||||
};
|
||||
|
||||
|
|
|
@ -1,49 +0,0 @@
|
|||
/*
|
||||
* linux/arch/arm/mach-mp1000/mp1000.c
|
||||
*
|
||||
* Copyright (C) 2005 Comdial Corporation
|
||||
*
|
||||
* 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
|
||||
*/
|
||||
#include <linux/init.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/string.h>
|
||||
|
||||
#include <asm/setup.h>
|
||||
#include <asm/mach-types.h>
|
||||
#include <asm/mach/arch.h>
|
||||
#include <asm/arch/mp1000-seprom.h>
|
||||
|
||||
#include "common.h"
|
||||
|
||||
extern void mp1000_map_io(void);
|
||||
|
||||
static void __init mp1000_init(void)
|
||||
{
|
||||
seprom_init();
|
||||
}
|
||||
|
||||
MACHINE_START(MP1000, "Comdial MP1000")
|
||||
/* Maintainer: Jon Ringle */
|
||||
.phys_ram = 0xc0000000,
|
||||
.phys_io = 0x80000000,
|
||||
.io_pg_offst = ((0xff000000) >> 18) & 0xfffc,
|
||||
.boot_params = 0xc0015100,
|
||||
.map_io = mp1000_map_io,
|
||||
.init_irq = clps711x_init_irq,
|
||||
.init_machine = mp1000_init,
|
||||
.timer = &clps711x_timer,
|
||||
MACHINE_END
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
/*
|
||||
* linux/arch/arm/mach-mp1000/mm.c
|
||||
*
|
||||
* Extra MM routines for the MP1000
|
||||
*
|
||||
* Copyright (C) 2005 Comdial Corporation
|
||||
*
|
||||
* 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
|
||||
*/
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/init.h>
|
||||
|
||||
#include <asm/hardware.h>
|
||||
#include <asm/page.h>
|
||||
#include <asm/pgtable.h>
|
||||
#include <asm/sizes.h>
|
||||
|
||||
#include <asm/mach/map.h>
|
||||
|
||||
extern void clps711x_map_io(void);
|
||||
|
||||
static struct map_desc mp1000_io_desc[] __initdata = {
|
||||
{ MP1000_EIO_BASE, MP1000_EIO_START, MP1000_EIO_SIZE, MT_DEVICE },
|
||||
{ MP1000_FIO_BASE, MP1000_FIO_START, MP1000_FIO_SIZE, MT_DEVICE },
|
||||
{ MP1000_LIO_BASE, MP1000_LIO_START, MP1000_LIO_SIZE, MT_DEVICE },
|
||||
{ MP1000_NIO_BASE, MP1000_NIO_START, MP1000_NIO_SIZE, MT_DEVICE },
|
||||
{ MP1000_IDE_BASE, MP1000_IDE_START, MP1000_IDE_SIZE, MT_DEVICE },
|
||||
{ MP1000_DSP_BASE, MP1000_DSP_START, MP1000_DSP_SIZE, MT_DEVICE }
|
||||
};
|
||||
|
||||
void __init mp1000_map_io(void)
|
||||
{
|
||||
clps711x_map_io();
|
||||
iotable_init(mp1000_io_desc, ARRAY_SIZE(mp1000_io_desc));
|
||||
}
|
|
@ -1,195 +0,0 @@
|
|||
/*`
|
||||
* mp1000-seprom.c
|
||||
*
|
||||
* This file contains the Serial EEPROM code for the MP1000 board
|
||||
*
|
||||
* Copyright (C) 2005 Comdial Corporation
|
||||
*
|
||||
* 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
|
||||
*
|
||||
*/
|
||||
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/init.h>
|
||||
#include <asm/hardware.h>
|
||||
#include <asm/hardware/clps7111.h>
|
||||
#include <asm/arch/mp1000-seprom.h>
|
||||
|
||||
/* If SepromInit() can initialize and checksum the seprom successfully, */
|
||||
/* then it will point seprom_data_ptr at the shadow copy. */
|
||||
|
||||
static eeprom_struct seprom_data; /* shadow copy of seprom content */
|
||||
|
||||
eeprom_struct *seprom_data_ptr = 0; /* 0 => not initialized */
|
||||
|
||||
/*
|
||||
* Port D Bit 5 is Chip Select for EEPROM
|
||||
* Port E Bit 0 is Input, Data out from EEPROM
|
||||
* Port E Bit 1 is Output, Data in to EEPROM
|
||||
* Port E Bit 2 is Output, CLK to EEPROM
|
||||
*/
|
||||
|
||||
static char *port_d_ptr = (char *)(CLPS7111_VIRT_BASE + PDDR);
|
||||
static char *port_e_ptr = (char *)(CLPS7111_VIRT_BASE + PEDR);
|
||||
|
||||
#define NO_OF_SHORTS 64 // Device is 64 x 16 bits
|
||||
#define ENABLE_RW 0
|
||||
#define DISABLE_RW 1
|
||||
|
||||
static inline void toggle_seprom_clock(void)
|
||||
{
|
||||
*port_e_ptr |= HwPortESepromCLK;
|
||||
*port_e_ptr &= ~(HwPortESepromCLK);
|
||||
}
|
||||
|
||||
static inline void select_eeprom(void)
|
||||
{
|
||||
*port_d_ptr |= HwPortDEECS;
|
||||
*port_e_ptr &= ~(HwPortESepromCLK);
|
||||
}
|
||||
|
||||
static inline void deselect_eeprom(void)
|
||||
{
|
||||
*port_d_ptr &= ~(HwPortDEECS);
|
||||
*port_e_ptr &= ~(HwPortESepromDIn);
|
||||
}
|
||||
|
||||
/*
|
||||
* GetSepromDataPtr - returns pointer to shadow (RAM) copy of seprom
|
||||
* and returns 0 if seprom is not initialized or
|
||||
* has a checksum error.
|
||||
*/
|
||||
|
||||
eeprom_struct* get_seprom_ptr(void)
|
||||
{
|
||||
return seprom_data_ptr;
|
||||
}
|
||||
|
||||
unsigned char* get_eeprom_mac_address(void)
|
||||
{
|
||||
return seprom_data_ptr->variant.eprom_struct.mac_Address;
|
||||
}
|
||||
|
||||
/*
|
||||
* ReadSProm, Physically reads data from the Serial PROM
|
||||
*/
|
||||
static void read_sprom(short address, int length, eeprom_struct *buffer)
|
||||
{
|
||||
short data = COMMAND_READ | (address & 0x3F);
|
||||
short bit;
|
||||
int i;
|
||||
|
||||
select_eeprom();
|
||||
|
||||
// Clock in 9 bits of the command
|
||||
for (i = 0, bit = 0x100; i < 9; i++, bit >>= 1) {
|
||||
if (data & bit)
|
||||
*port_e_ptr |= HwPortESepromDIn;
|
||||
else
|
||||
*port_e_ptr &= ~(HwPortESepromDIn);
|
||||
|
||||
toggle_seprom_clock();
|
||||
}
|
||||
|
||||
//
|
||||
// Now read one or more shorts of data from the Seprom
|
||||
//
|
||||
while (length-- > 0) {
|
||||
data = 0;
|
||||
|
||||
// Read 16 bits at a time
|
||||
for (i = 0; i < 16; i++) {
|
||||
data <<= 1;
|
||||
toggle_seprom_clock();
|
||||
data |= *port_e_ptr & HwPortESepromDOut;
|
||||
|
||||
}
|
||||
|
||||
buffer->variant.eprom_short_data[address++] = data;
|
||||
}
|
||||
|
||||
deselect_eeprom();
|
||||
|
||||
return;
|
||||
}
|
||||
|
||||
|
||||
|
||||
/*
|
||||
* ReadSerialPROM
|
||||
*
|
||||
* Input: Pointer to array of 64 x 16 Bits
|
||||
*
|
||||
* Output: if no problem reading data is filled in
|
||||
*/
|
||||
static void read_serial_prom(eeprom_struct *data)
|
||||
{
|
||||
read_sprom(0, 64, data);
|
||||
}
|
||||
|
||||
|
||||
//
|
||||
// Compute Serial EEPROM checksum
|
||||
//
|
||||
// Input: Pointer to struct with Eprom data
|
||||
//
|
||||
// Output: The computed Eprom checksum
|
||||
//
|
||||
static short compute_seprom_checksum(eeprom_struct *data)
|
||||
{
|
||||
short checksum = 0;
|
||||
int i;
|
||||
|
||||
for (i = 0; i < 126; i++) {
|
||||
checksum += (short)data->variant.eprom_byte_data[i];
|
||||
}
|
||||
|
||||
return((short)(0x5555 - (checksum & 0xFFFF)));
|
||||
}
|
||||
|
||||
//
|
||||
// Make sure the data port bits for the SEPROM are correctly initialised
|
||||
//
|
||||
|
||||
void __init seprom_init(void)
|
||||
{
|
||||
short checksum;
|
||||
|
||||
// Init Port D
|
||||
*(char *)(CLPS7111_VIRT_BASE + PDDDR) = 0x0;
|
||||
*(char *)(CLPS7111_VIRT_BASE + PDDR) = 0x15;
|
||||
|
||||
// Init Port E
|
||||
*(int *)(CLPS7111_VIRT_BASE + PEDDR) = 0x06;
|
||||
*(int *)(CLPS7111_VIRT_BASE + PEDR) = 0x04;
|
||||
|
||||
//
|
||||
// Make sure that EEPROM struct size never exceeds 128 bytes
|
||||
//
|
||||
if (sizeof(eeprom_struct) > 128) {
|
||||
panic("Serial PROM struct size > 128, aborting read\n");
|
||||
}
|
||||
|
||||
read_serial_prom(&seprom_data);
|
||||
|
||||
checksum = compute_seprom_checksum(&seprom_data);
|
||||
|
||||
if (checksum != seprom_data.variant.eprom_short_data[63]) {
|
||||
panic("Serial EEPROM checksum failed\n");
|
||||
}
|
||||
|
||||
seprom_data_ptr = &seprom_data;
|
||||
}
|
||||
|
|
@ -25,6 +25,7 @@
|
|||
#include <asm/hardware.h>
|
||||
#include <asm/io.h>
|
||||
#include <asm/sizes.h>
|
||||
#include <asm/page.h>
|
||||
|
||||
#include <asm/mach/map.h>
|
||||
|
||||
|
|
|
@ -420,8 +420,7 @@ static int impd1_probe(struct lm_device *dev)
|
|||
free_impd1:
|
||||
if (impd1 && impd1->base)
|
||||
iounmap(impd1->base);
|
||||
if (impd1)
|
||||
kfree(impd1);
|
||||
kfree(impd1);
|
||||
release_lm:
|
||||
release_mem_region(dev->resource.start, SZ_4K);
|
||||
return ret;
|
||||
|
|
|
@ -84,63 +84,54 @@ static struct map_desc ixp2000_io_desc[] __initdata = {
|
|||
.virtual = IXP2000_CAP_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_CAP_PHYS_BASE),
|
||||
.length = IXP2000_CAP_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_INTCTL_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_INTCTL_PHYS_BASE),
|
||||
.length = IXP2000_INTCTL_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_PCI_CREG_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_PCI_CREG_PHYS_BASE),
|
||||
.length = IXP2000_PCI_CREG_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_PCI_CSR_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_PCI_CSR_PHYS_BASE),
|
||||
.length = IXP2000_PCI_CSR_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_MSF_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_MSF_PHYS_BASE),
|
||||
.length = IXP2000_MSF_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_PCI_IO_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_PCI_IO_PHYS_BASE),
|
||||
.length = IXP2000_PCI_IO_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_PCI_CFG0_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_PCI_CFG0_PHYS_BASE),
|
||||
.length = IXP2000_PCI_CFG0_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = IXP2000_PCI_CFG1_VIRT_BASE,
|
||||
.pfn = __phys_to_pfn(IXP2000_PCI_CFG1_PHYS_BASE),
|
||||
.length = IXP2000_PCI_CFG1_SIZE,
|
||||
.type = MT_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}
|
||||
};
|
||||
|
||||
void __init ixp2000_map_io(void)
|
||||
{
|
||||
extern unsigned int processor_id;
|
||||
|
||||
/*
|
||||
* On IXP2400 CPUs we need to use MT_IXP2000_DEVICE for
|
||||
* tweaking the PMDs so XCB=101. On IXP2800s we use the normal
|
||||
* PMD flags.
|
||||
* On IXP2400 CPUs we need to use MT_IXP2000_DEVICE so that
|
||||
* XCB=101 (to avoid triggering erratum #66), and given that
|
||||
* this mode speeds up I/O accesses and we have write buffer
|
||||
* flushes in the right places anyway, it doesn't hurt to use
|
||||
* XCB=101 for all IXP2000s.
|
||||
*/
|
||||
if ((processor_id & 0xfffffff0) == 0x69054190) {
|
||||
int i;
|
||||
|
||||
printk(KERN_INFO "Enabling IXP2400 erratum #66 workaround\n");
|
||||
|
||||
for(i=0;i<ARRAY_SIZE(ixp2000_io_desc);i++)
|
||||
ixp2000_io_desc[i].type = MT_IXP2000_DEVICE;
|
||||
}
|
||||
|
||||
iotable_init(ixp2000_io_desc, ARRAY_SIZE(ixp2000_io_desc));
|
||||
|
||||
/* Set slowport to 8-bit mode. */
|
||||
|
@ -402,6 +393,40 @@ static void ixp2000_pci_irq_unmask(unsigned int irq)
|
|||
ixp2000_reg_write(IXP2000_PCI_XSCALE_INT_ENABLE, (temp | (1 << 27)));
|
||||
}
|
||||
|
||||
/*
|
||||
* Error interrupts. These are used extensively by the microengine drivers
|
||||
*/
|
||||
static void ixp2000_err_irq_handler(unsigned int irq, struct irqdesc *desc, struct pt_regs *regs)
|
||||
{
|
||||
int i;
|
||||
unsigned long status = *IXP2000_IRQ_ERR_STATUS;
|
||||
|
||||
for(i = 31; i >= 0; i--) {
|
||||
if(status & (1 << i)) {
|
||||
desc = irq_desc + IRQ_IXP2000_DRAM0_MIN_ERR + i;
|
||||
desc->handle(IRQ_IXP2000_DRAM0_MIN_ERR + i, desc, regs);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
static void ixp2000_err_irq_mask(unsigned int irq)
|
||||
{
|
||||
ixp2000_reg_write(IXP2000_IRQ_ERR_ENABLE_CLR,
|
||||
(1 << (irq - IRQ_IXP2000_DRAM0_MIN_ERR)));
|
||||
}
|
||||
|
||||
static void ixp2000_err_irq_unmask(unsigned int irq)
|
||||
{
|
||||
ixp2000_reg_write(IXP2000_IRQ_ERR_ENABLE_SET,
|
||||
(1 << (irq - IRQ_IXP2000_DRAM0_MIN_ERR)));
|
||||
}
|
||||
|
||||
static struct irqchip ixp2000_err_irq_chip = {
|
||||
.ack = ixp2000_err_irq_mask,
|
||||
.mask = ixp2000_err_irq_mask,
|
||||
.unmask = ixp2000_err_irq_unmask
|
||||
};
|
||||
|
||||
static struct irqchip ixp2000_pci_irq_chip = {
|
||||
.ack = ixp2000_pci_irq_mask,
|
||||
.mask = ixp2000_pci_irq_mask,
|
||||
|
@ -459,6 +484,18 @@ void __init ixp2000_init_irq(void)
|
|||
} else set_irq_flags(irq, 0);
|
||||
}
|
||||
|
||||
for (irq = IRQ_IXP2000_DRAM0_MIN_ERR; irq <= IRQ_IXP2000_SP_INT; irq++) {
|
||||
if((1 << (irq - IRQ_IXP2000_DRAM0_MIN_ERR)) &
|
||||
IXP2000_VALID_ERR_IRQ_MASK) {
|
||||
set_irq_chip(irq, &ixp2000_err_irq_chip);
|
||||
set_irq_handler(irq, do_level_IRQ);
|
||||
set_irq_flags(irq, IRQF_VALID);
|
||||
}
|
||||
else
|
||||
set_irq_flags(irq, 0);
|
||||
}
|
||||
set_irq_chained_handler(IRQ_IXP2000_ERRSUM, ixp2000_err_irq_handler);
|
||||
|
||||
/*
|
||||
* GPIO IRQs are invalid until someone sets the interrupt mode
|
||||
* by calling set_irq_type().
|
||||
|
|
|
@ -69,19 +69,19 @@ static struct sys_timer enp2611_timer = {
|
|||
static struct map_desc enp2611_io_desc[] __initdata = {
|
||||
{
|
||||
.virtual = ENP2611_CALEB_VIRT_BASE,
|
||||
.physical = ENP2611_CALEB_PHYS_BASE,
|
||||
.pfn = __phys_to_pfn(ENP2611_CALEB_PHYS_BASE),
|
||||
.length = ENP2611_CALEB_SIZE,
|
||||
.type = MT_IXP2000_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = ENP2611_PM3386_0_VIRT_BASE,
|
||||
.physical = ENP2611_PM3386_0_PHYS_BASE,
|
||||
.pfn = __phys_to_pfn(ENP2611_PM3386_0_PHYS_BASE),
|
||||
.length = ENP2611_PM3386_0_SIZE,
|
||||
.type = MT_IXP2000_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}, {
|
||||
.virtual = ENP2611_PM3386_1_VIRT_BASE,
|
||||
.physical = ENP2611_PM3386_1_PHYS_BASE,
|
||||
.pfn = __phys_to_pfn(ENP2611_PM3386_1_PHYS_BASE),
|
||||
.length = ENP2611_PM3386_1_SIZE,
|
||||
.type = MT_IXP2000_DEVICE
|
||||
.type = MT_IXP2000_DEVICE,
|
||||
}
|
||||
};
|
||||
|
||||
|
|
|
@ -91,8 +91,8 @@ EXPORT_SYMBOL(ixp2000_uengine_csr_write);
|
|||
|
||||
void ixp2000_uengine_reset(u32 uengine_mask)
|
||||
{
|
||||
ixp2000_reg_write(IXP2000_RESET1, uengine_mask & ixp2000_uengine_mask);
|
||||
ixp2000_reg_write(IXP2000_RESET1, 0);
|
||||
ixp2000_reg_wrb(IXP2000_RESET1, uengine_mask & ixp2000_uengine_mask);
|
||||
ixp2000_reg_wrb(IXP2000_RESET1, 0);
|
||||
}
|
||||
EXPORT_SYMBOL(ixp2000_uengine_reset);
|
||||
|
||||
|
@ -452,21 +452,20 @@ static int __init ixp2000_uengine_init(void)
|
|||
/*
|
||||
* Reset microengines.
|
||||
*/
|
||||
ixp2000_reg_write(IXP2000_RESET1, ixp2000_uengine_mask);
|
||||
ixp2000_reg_write(IXP2000_RESET1, 0);
|
||||
ixp2000_uengine_reset(ixp2000_uengine_mask);
|
||||
|
||||
/*
|
||||
* Synchronise timestamp counters across all microengines.
|
||||
*/
|
||||
value = ixp2000_reg_read(IXP2000_MISC_CONTROL);
|
||||
ixp2000_reg_write(IXP2000_MISC_CONTROL, value & ~0x80);
|
||||
ixp2000_reg_wrb(IXP2000_MISC_CONTROL, value & ~0x80);
|
||||
for (uengine = 0; uengine < 32; uengine++) {
|
||||
if (ixp2000_uengine_mask & (1 << uengine)) {
|
||||
ixp2000_uengine_csr_write(uengine, TIMESTAMP_LOW, 0);
|
||||
ixp2000_uengine_csr_write(uengine, TIMESTAMP_HIGH, 0);
|
||||
}
|
||||
}
|
||||
ixp2000_reg_write(IXP2000_MISC_CONTROL, value | 0x80);
|
||||
ixp2000_reg_wrb(IXP2000_MISC_CONTROL, value | 0x80);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
|
|
@ -427,7 +427,7 @@ void __init ixp4xx_pci_preinit(void)
|
|||
#ifdef __ARMEB__
|
||||
*PCI_CSR = PCI_CSR_IC | PCI_CSR_ABE | PCI_CSR_PDS | PCI_CSR_ADS;
|
||||
#else
|
||||
*PCI_CSR = PCI_CSR_IC;
|
||||
*PCI_CSR = PCI_CSR_IC | PCI_CSR_ABE;
|
||||
#endif
|
||||
|
||||
pr_debug("DONE\n");
|
||||
|
|
|
@ -13,7 +13,6 @@
|
|||
#include <linux/init.h>
|
||||
#include <linux/kernel_stat.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/version.h>
|
||||
|
||||
#include <asm/io.h>
|
||||
#include <asm/hardware.h>
|
||||
|
|
|
@ -27,7 +27,8 @@ config PXA_SHARPSL
|
|||
Say Y here if you intend to run this kernel on a
|
||||
Sharp Zaurus SL-5600 (Poodle), SL-C700 (Corgi),
|
||||
SL-C750 (Shepherd), SL-C760 (Husky), SL-C1000 (Akita),
|
||||
SL-C3000 (Spitz) or SL-C3100 (Borzoi) handheld computer.
|
||||
SL-C3000 (Spitz), SL-C3100 (Borzoi) or SL-C6000x (Tosa)
|
||||
handheld computer.
|
||||
|
||||
endchoice
|
||||
|
||||
|
@ -37,7 +38,7 @@ choice
|
|||
prompt "Select target Sharp Zaurus device range"
|
||||
|
||||
config PXA_SHARPSL_25x
|
||||
bool "Sharp PXA25x models (SL-5600 and SL-C7xx)"
|
||||
bool "Sharp PXA25x models (SL-5600, SL-C7xx and SL-C6000x)"
|
||||
select PXA25x
|
||||
|
||||
config PXA_SHARPSL_27x
|
||||
|
@ -80,6 +81,10 @@ config MACH_BORZOI
|
|||
depends PXA_SHARPSL_27x
|
||||
select PXA_SHARP_Cxx00
|
||||
|
||||
config MACH_TOSA
|
||||
bool "Enable Sharp SL-6000x (Tosa) Support"
|
||||
depends PXA_SHARPSL
|
||||
|
||||
config PXA25x
|
||||
bool
|
||||
help
|
||||
|
|
|
@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_PXA_IDP) += idp.o
|
|||
obj-$(CONFIG_PXA_SHARP_C7xx) += corgi.o corgi_ssp.o corgi_lcd.o ssp.o
|
||||
obj-$(CONFIG_PXA_SHARP_Cxx00) += spitz.o corgi_ssp.o corgi_lcd.o ssp.o
|
||||
obj-$(CONFIG_MACH_POODLE) += poodle.o
|
||||
obj-$(CONFIG_MACH_TOSA) += tosa.o
|
||||
|
||||
# Support for blinky lights
|
||||
led-y := leds.o
|
||||
|
|
|
@ -62,15 +62,6 @@ static struct scoop_config corgi_scoop_setup = {
|
|||
.io_out = CORGI_SCOOP_IO_OUT,
|
||||
};
|
||||
|
||||
static struct scoop_pcmcia_dev corgi_pcmcia_scoop[] = {
|
||||
{
|
||||
.dev = &corgiscoop_device.dev,
|
||||
.irq = CORGI_IRQ_GPIO_CF_IRQ,
|
||||
.cd_irq = CORGI_IRQ_GPIO_CF_CD,
|
||||
.cd_irq_str = "PCMCIA0 CD",
|
||||
},
|
||||
};
|
||||
|
||||
struct platform_device corgiscoop_device = {
|
||||
.name = "sharp-scoop",
|
||||
.id = -1,
|
||||
|
@ -81,6 +72,44 @@ struct platform_device corgiscoop_device = {
|
|||
.resource = corgi_scoop_resources,
|
||||
};
|
||||
|
||||
static void corgi_pcmcia_init(void)
|
||||
{
|
||||
/* Setup default state of GPIO outputs
|
||||
before we enable them as outputs. */
|
||||
GPSR(GPIO48_nPOE) = GPIO_bit(GPIO48_nPOE) |
|
||||
GPIO_bit(GPIO49_nPWE) | GPIO_bit(GPIO50_nPIOR) |
|
||||
GPIO_bit(GPIO51_nPIOW) | GPIO_bit(GPIO52_nPCE_1) |
|
||||
GPIO_bit(GPIO53_nPCE_2);
|
||||
|
||||
pxa_gpio_mode(GPIO48_nPOE_MD);
|
||||
pxa_gpio_mode(GPIO49_nPWE_MD);
|
||||
pxa_gpio_mode(GPIO50_nPIOR_MD);
|
||||
pxa_gpio_mode(GPIO51_nPIOW_MD);
|
||||
pxa_gpio_mode(GPIO55_nPREG_MD);
|
||||
pxa_gpio_mode(GPIO56_nPWAIT_MD);
|
||||
pxa_gpio_mode(GPIO57_nIOIS16_MD);
|
||||
pxa_gpio_mode(GPIO52_nPCE_1_MD);
|
||||
pxa_gpio_mode(GPIO53_nPCE_2_MD);
|
||||
pxa_gpio_mode(GPIO54_pSKTSEL_MD);
|
||||
}
|
||||
|
||||
static struct scoop_pcmcia_dev corgi_pcmcia_scoop[] = {
|
||||
{
|
||||
.dev = &corgiscoop_device.dev,
|
||||
.irq = CORGI_IRQ_GPIO_CF_IRQ,
|
||||
.cd_irq = CORGI_IRQ_GPIO_CF_CD,
|
||||
.cd_irq_str = "PCMCIA0 CD",
|
||||
},
|
||||
};
|
||||
|
||||
static struct scoop_pcmcia_config corgi_pcmcia_config = {
|
||||
.devs = &corgi_pcmcia_scoop[0],
|
||||
.num_devs = 1,
|
||||
.pcmcia_init = corgi_pcmcia_init,
|
||||
};
|
||||
|
||||
EXPORT_SYMBOL(corgiscoop_device);
|
||||
|
||||
|
||||
/*
|
||||
* Corgi SSP Device
|
||||
|
@ -294,8 +323,7 @@ static void __init corgi_init(void)
|
|||
pxa_set_mci_info(&corgi_mci_platform_data);
|
||||
pxa_set_ficp_info(&corgi_ficp_platform_data);
|
||||
|
||||
scoop_num = 1;
|
||||
scoop_devs = &corgi_pcmcia_scoop[0];
|
||||
platform_scoop_config = &corgi_pcmcia_config;
|
||||
|
||||
platform_add_devices(devices, ARRAY_SIZE(devices));
|
||||
}
|
||||
|
|
|
@ -19,6 +19,7 @@
|
|||
#include <linux/kernel.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/string.h>
|
||||
#include <asm/arch/akita.h>
|
||||
#include <asm/arch/corgi.h>
|
||||
#include <asm/arch/hardware.h>
|
||||
|
|
|
@ -19,16 +19,20 @@
|
|||
#include <linux/major.h>
|
||||
#include <linux/fb.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
|
||||
#include <asm/setup.h>
|
||||
#include <asm/memory.h>
|
||||
#include <asm/mach-types.h>
|
||||
#include <asm/hardware.h>
|
||||
#include <asm/irq.h>
|
||||
#include <asm/sizes.h>
|
||||
|
||||
#include <asm/mach/arch.h>
|
||||
#include <asm/mach/map.h>
|
||||
#include <asm/mach/irq.h>
|
||||
#include <asm/mach/flash.h>
|
||||
|
||||
#include <asm/hardware/sa1111.h>
|
||||
|
||||
|
@ -199,10 +203,75 @@ static struct platform_device smc91x_device = {
|
|||
.resource = smc91x_resources,
|
||||
};
|
||||
|
||||
static struct resource flash_resources[] = {
|
||||
[0] = {
|
||||
.start = 0x00000000,
|
||||
.end = SZ_64M - 1,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
[1] = {
|
||||
.start = 0x04000000,
|
||||
.end = 0x04000000 + SZ_64M - 1,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
};
|
||||
|
||||
static struct mtd_partition lubbock_partitions[] = {
|
||||
{
|
||||
.name = "Bootloader",
|
||||
.size = 0x00040000,
|
||||
.offset = 0,
|
||||
.mask_flags = MTD_WRITEABLE /* force read-only */
|
||||
},{
|
||||
.name = "Kernel",
|
||||
.size = 0x00100000,
|
||||
.offset = 0x00040000,
|
||||
},{
|
||||
.name = "Filesystem",
|
||||
.size = MTDPART_SIZ_FULL,
|
||||
.offset = 0x00140000
|
||||
}
|
||||
};
|
||||
|
||||
static struct flash_platform_data lubbock_flash_data[2] = {
|
||||
{
|
||||
.map_name = "cfi_probe",
|
||||
.parts = lubbock_partitions,
|
||||
.nr_parts = ARRAY_SIZE(lubbock_partitions),
|
||||
}, {
|
||||
.map_name = "cfi_probe",
|
||||
.parts = NULL,
|
||||
.nr_parts = 0,
|
||||
}
|
||||
};
|
||||
|
||||
static struct platform_device lubbock_flash_device[2] = {
|
||||
{
|
||||
.name = "pxa2xx-flash",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.platform_data = &lubbock_flash_data[0],
|
||||
},
|
||||
.resource = &flash_resources[0],
|
||||
.num_resources = 1,
|
||||
},
|
||||
{
|
||||
.name = "pxa2xx-flash",
|
||||
.id = 1,
|
||||
.dev = {
|
||||
.platform_data = &lubbock_flash_data[1],
|
||||
},
|
||||
.resource = &flash_resources[1],
|
||||
.num_resources = 1,
|
||||
},
|
||||
};
|
||||
|
||||
static struct platform_device *devices[] __initdata = {
|
||||
&sa1111_device,
|
||||
&lub_audio_device,
|
||||
&smc91x_device,
|
||||
&lubbock_flash_device[0],
|
||||
&lubbock_flash_device[1],
|
||||
};
|
||||
|
||||
static struct pxafb_mach_info sharp_lm8v31 __initdata = {
|
||||
|
@ -315,10 +384,21 @@ static struct pxaficp_platform_data lubbock_ficp_platform_data = {
|
|||
|
||||
static void __init lubbock_init(void)
|
||||
{
|
||||
int flashboot = (LUB_CONF_SWITCHES & 1);
|
||||
|
||||
pxa_set_udc_info(&udc_info);
|
||||
set_pxa_fb_info(&sharp_lm8v31);
|
||||
pxa_set_mci_info(&lubbock_mci_platform_data);
|
||||
pxa_set_ficp_info(&lubbock_ficp_platform_data);
|
||||
|
||||
lubbock_flash_data[0].width = lubbock_flash_data[1].width =
|
||||
(BOOT_DEF & 1) ? 2 : 4;
|
||||
/* Compensate for the nROMBT switch which swaps the flash banks */
|
||||
printk(KERN_NOTICE "Lubbock configured to boot from %s (bank %d)\n",
|
||||
flashboot?"Flash":"ROM", flashboot);
|
||||
|
||||
lubbock_flash_data[flashboot^1].name = "application-flash";
|
||||
lubbock_flash_data[flashboot].name = "boot-rom";
|
||||
(void) platform_add_devices(devices, ARRAY_SIZE(devices));
|
||||
}
|
||||
|
||||
|
|
|
@ -20,6 +20,9 @@
|
|||
#include <linux/sched.h>
|
||||
#include <linux/bitops.h>
|
||||
#include <linux/fb.h>
|
||||
#include <linux/ioport.h>
|
||||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
|
||||
#include <asm/types.h>
|
||||
#include <asm/setup.h>
|
||||
|
@ -27,10 +30,12 @@
|
|||
#include <asm/mach-types.h>
|
||||
#include <asm/hardware.h>
|
||||
#include <asm/irq.h>
|
||||
#include <asm/sizes.h>
|
||||
|
||||
#include <asm/mach/arch.h>
|
||||
#include <asm/mach/map.h>
|
||||
#include <asm/mach/irq.h>
|
||||
#include <asm/mach/flash.h>
|
||||
|
||||
#include <asm/arch/pxa-regs.h>
|
||||
#include <asm/arch/mainstone.h>
|
||||
|
@ -190,6 +195,69 @@ static struct platform_device mst_audio_device = {
|
|||
.dev = { .platform_data = &mst_audio_ops },
|
||||
};
|
||||
|
||||
static struct resource flash_resources[] = {
|
||||
[0] = {
|
||||
.start = PXA_CS0_PHYS,
|
||||
.end = PXA_CS0_PHYS + SZ_64M - 1,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
[1] = {
|
||||
.start = PXA_CS1_PHYS,
|
||||
.end = PXA_CS1_PHYS + SZ_64M - 1,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
};
|
||||
|
||||
static struct mtd_partition mainstoneflash0_partitions[] = {
|
||||
{
|
||||
.name = "Bootloader",
|
||||
.size = 0x00040000,
|
||||
.offset = 0,
|
||||
.mask_flags = MTD_WRITEABLE /* force read-only */
|
||||
},{
|
||||
.name = "Kernel",
|
||||
.size = 0x00400000,
|
||||
.offset = 0x00040000,
|
||||
},{
|
||||
.name = "Filesystem",
|
||||
.size = MTDPART_SIZ_FULL,
|
||||
.offset = 0x00440000
|
||||
}
|
||||
};
|
||||
|
||||
static struct flash_platform_data mst_flash_data[2] = {
|
||||
{
|
||||
.map_name = "cfi_probe",
|
||||
.parts = mainstoneflash0_partitions,
|
||||
.nr_parts = ARRAY_SIZE(mainstoneflash0_partitions),
|
||||
}, {
|
||||
.map_name = "cfi_probe",
|
||||
.parts = NULL,
|
||||
.nr_parts = 0,
|
||||
}
|
||||
};
|
||||
|
||||
static struct platform_device mst_flash_device[2] = {
|
||||
{
|
||||
.name = "pxa2xx-flash",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.platform_data = &mst_flash_data[0],
|
||||
},
|
||||
.resource = &flash_resources[0],
|
||||
.num_resources = 1,
|
||||
},
|
||||
{
|
||||
.name = "pxa2xx-flash",
|
||||
.id = 1,
|
||||
.dev = {
|
||||
.platform_data = &mst_flash_data[1],
|
||||
},
|
||||
.resource = &flash_resources[1],
|
||||
.num_resources = 1,
|
||||
},
|
||||
};
|
||||
|
||||
static void mainstone_backlight_power(int on)
|
||||
{
|
||||
if (on) {
|
||||
|
@ -318,16 +386,34 @@ static struct pxaficp_platform_data mainstone_ficp_platform_data = {
|
|||
.transceiver_mode = mainstone_irda_transceiver_mode,
|
||||
};
|
||||
|
||||
static struct platform_device *platform_devices[] __initdata = {
|
||||
&smc91x_device,
|
||||
&mst_audio_device,
|
||||
&mst_flash_device[0],
|
||||
&mst_flash_device[1],
|
||||
};
|
||||
|
||||
static void __init mainstone_init(void)
|
||||
{
|
||||
int SW7 = 0; /* FIXME: get from SCR (Mst doc section 3.2.1.1) */
|
||||
|
||||
mst_flash_data[0].width = (BOOT_DEF & 1) ? 2 : 4;
|
||||
mst_flash_data[1].width = 4;
|
||||
|
||||
/* Compensate for SW7 which swaps the flash banks */
|
||||
mst_flash_data[SW7].name = "processor-flash";
|
||||
mst_flash_data[SW7 ^ 1].name = "mainboard-flash";
|
||||
|
||||
printk(KERN_NOTICE "Mainstone configured to boot from %s\n",
|
||||
mst_flash_data[0].name);
|
||||
|
||||
/*
|
||||
* On Mainstone, we route AC97_SYSCLK via GPIO45 to
|
||||
* the audio daughter card
|
||||
*/
|
||||
pxa_gpio_mode(GPIO45_SYSCLK_AC97_MD);
|
||||
|
||||
platform_device_register(&smc91x_device);
|
||||
platform_device_register(&mst_audio_device);
|
||||
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
|
||||
|
||||
/* reading Mainstone's "Virtual Configuration Register"
|
||||
might be handy to select LCD type here */
|
||||
|
|
|
@ -12,6 +12,7 @@
|
|||
*/
|
||||
#include <linux/config.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/suspend.h>
|
||||
#include <linux/errno.h>
|
||||
#include <linux/time.h>
|
||||
|
@ -19,6 +20,7 @@
|
|||
#include <asm/hardware.h>
|
||||
#include <asm/memory.h>
|
||||
#include <asm/system.h>
|
||||
#include <asm/arch/pm.h>
|
||||
#include <asm/arch/pxa-regs.h>
|
||||
#include <asm/arch/lubbock.h>
|
||||
#include <asm/mach/time.h>
|
||||
|
@ -72,7 +74,7 @@ enum { SLEEP_SAVE_START = 0,
|
|||
};
|
||||
|
||||
|
||||
static int pxa_pm_enter(suspend_state_t state)
|
||||
int pxa_pm_enter(suspend_state_t state)
|
||||
{
|
||||
unsigned long sleep_save[SLEEP_SAVE_SIZE];
|
||||
unsigned long checksum = 0;
|
||||
|
@ -191,6 +193,8 @@ static int pxa_pm_enter(suspend_state_t state)
|
|||
return 0;
|
||||
}
|
||||
|
||||
EXPORT_SYMBOL_GPL(pxa_pm_enter);
|
||||
|
||||
unsigned long sleep_phys_sp(void *sp)
|
||||
{
|
||||
return virt_to_phys(sp);
|
||||
|
@ -199,21 +203,25 @@ unsigned long sleep_phys_sp(void *sp)
|
|||
/*
|
||||
* Called after processes are frozen, but before we shut down devices.
|
||||
*/
|
||||
static int pxa_pm_prepare(suspend_state_t state)
|
||||
int pxa_pm_prepare(suspend_state_t state)
|
||||
{
|
||||
extern int pxa_cpu_pm_prepare(suspend_state_t state);
|
||||
|
||||
return pxa_cpu_pm_prepare(state);
|
||||
}
|
||||
|
||||
EXPORT_SYMBOL_GPL(pxa_pm_prepare);
|
||||
|
||||
/*
|
||||
* Called after devices are re-setup, but before processes are thawed.
|
||||
*/
|
||||
static int pxa_pm_finish(suspend_state_t state)
|
||||
int pxa_pm_finish(suspend_state_t state)
|
||||
{
|
||||
return 0;
|
||||
}
|
||||
|
||||
EXPORT_SYMBOL_GPL(pxa_pm_finish);
|
||||
|
||||
/*
|
||||
* Set to PM_DISK_FIRMWARE so we can quickly veto suspend-to-disk.
|
||||
*/
|
||||
|
@ -230,4 +238,4 @@ static int __init pxa_pm_init(void)
|
|||
return 0;
|
||||
}
|
||||
|
||||
late_initcall(pxa_pm_init);
|
||||
device_initcall(pxa_pm_init);
|
||||
|
|
|
@ -65,6 +65,27 @@ struct platform_device poodle_scoop_device = {
|
|||
.resource = poodle_scoop_resources,
|
||||
};
|
||||
|
||||
static void poodle_pcmcia_init(void)
|
||||
{
|
||||
/* Setup default state of GPIO outputs
|
||||
before we enable them as outputs. */
|
||||
GPSR(GPIO48_nPOE) = GPIO_bit(GPIO48_nPOE) |
|
||||
GPIO_bit(GPIO49_nPWE) | GPIO_bit(GPIO50_nPIOR) |
|
||||
GPIO_bit(GPIO51_nPIOW) | GPIO_bit(GPIO52_nPCE_1) |
|
||||
GPIO_bit(GPIO53_nPCE_2);
|
||||
|
||||
pxa_gpio_mode(GPIO48_nPOE_MD);
|
||||
pxa_gpio_mode(GPIO49_nPWE_MD);
|
||||
pxa_gpio_mode(GPIO50_nPIOR_MD);
|
||||
pxa_gpio_mode(GPIO51_nPIOW_MD);
|
||||
pxa_gpio_mode(GPIO55_nPREG_MD);
|
||||
pxa_gpio_mode(GPIO56_nPWAIT_MD);
|
||||
pxa_gpio_mode(GPIO57_nIOIS16_MD);
|
||||
pxa_gpio_mode(GPIO52_nPCE_1_MD);
|
||||
pxa_gpio_mode(GPIO53_nPCE_2_MD);
|
||||
pxa_gpio_mode(GPIO54_pSKTSEL_MD);
|
||||
}
|
||||
|
||||
static struct scoop_pcmcia_dev poodle_pcmcia_scoop[] = {
|
||||
{
|
||||
.dev = &poodle_scoop_device.dev,
|
||||
|
@ -74,6 +95,14 @@ static struct scoop_pcmcia_dev poodle_pcmcia_scoop[] = {
|
|||
},
|
||||
};
|
||||
|
||||
static struct scoop_pcmcia_config poodle_pcmcia_config = {
|
||||
.devs = &poodle_pcmcia_scoop[0],
|
||||
.num_devs = 1,
|
||||
.pcmcia_init = poodle_pcmcia_init,
|
||||
};
|
||||
|
||||
EXPORT_SYMBOL(poodle_scoop_device);
|
||||
|
||||
|
||||
/* LoCoMo device */
|
||||
static struct resource locomo_resources[] = {
|
||||
|
@ -268,8 +297,7 @@ static void __init poodle_init(void)
|
|||
pxa_set_mci_info(&poodle_mci_platform_data);
|
||||
pxa_set_ficp_info(&poodle_ficp_platform_data);
|
||||
|
||||
scoop_num = 1;
|
||||
scoop_devs = &poodle_pcmcia_scoop[0];
|
||||
platform_scoop_config = &poodle_pcmcia_config;
|
||||
|
||||
ret = platform_add_devices(devices, ARRAY_SIZE(devices));
|
||||
if (ret) {
|
||||
|
|
|
@ -104,6 +104,66 @@ struct platform_device spitzscoop2_device = {
|
|||
.resource = spitz_scoop2_resources,
|
||||
};
|
||||
|
||||
#define SPITZ_PWR_SD 0x01
|
||||
#define SPITZ_PWR_CF 0x02
|
||||
|
||||
/* Power control is shared with between one of the CF slots and SD */
|
||||
static void spitz_card_pwr_ctrl(int device, unsigned short new_cpr)
|
||||
{
|
||||
unsigned short cpr = read_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR);
|
||||
|
||||
if (new_cpr & 0x0007) {
|
||||
set_scoop_gpio(&spitzscoop_device.dev, SPITZ_SCP_CF_POWER);
|
||||
if (!(cpr & 0x0002) && !(cpr & 0x0004))
|
||||
mdelay(5);
|
||||
if (device == SPITZ_PWR_CF)
|
||||
cpr |= 0x0002;
|
||||
if (device == SPITZ_PWR_SD)
|
||||
cpr |= 0x0004;
|
||||
write_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR, cpr | new_cpr);
|
||||
} else {
|
||||
if (device == SPITZ_PWR_CF)
|
||||
cpr &= ~0x0002;
|
||||
if (device == SPITZ_PWR_SD)
|
||||
cpr &= ~0x0004;
|
||||
write_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR, cpr | new_cpr);
|
||||
if (!(cpr & 0x0002) && !(cpr & 0x0004)) {
|
||||
mdelay(1);
|
||||
reset_scoop_gpio(&spitzscoop_device.dev, SPITZ_SCP_CF_POWER);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
static void spitz_pcmcia_init(void)
|
||||
{
|
||||
/* Setup default state of GPIO outputs
|
||||
before we enable them as outputs. */
|
||||
GPSR(GPIO48_nPOE) = GPIO_bit(GPIO48_nPOE) |
|
||||
GPIO_bit(GPIO49_nPWE) | GPIO_bit(GPIO50_nPIOR) |
|
||||
GPIO_bit(GPIO51_nPIOW) | GPIO_bit(GPIO54_nPCE_2);
|
||||
GPSR(GPIO85_nPCE_1) = GPIO_bit(GPIO85_nPCE_1);
|
||||
|
||||
pxa_gpio_mode(GPIO48_nPOE_MD);
|
||||
pxa_gpio_mode(GPIO49_nPWE_MD);
|
||||
pxa_gpio_mode(GPIO50_nPIOR_MD);
|
||||
pxa_gpio_mode(GPIO51_nPIOW_MD);
|
||||
pxa_gpio_mode(GPIO55_nPREG_MD);
|
||||
pxa_gpio_mode(GPIO56_nPWAIT_MD);
|
||||
pxa_gpio_mode(GPIO57_nIOIS16_MD);
|
||||
pxa_gpio_mode(GPIO85_nPCE_1_MD);
|
||||
pxa_gpio_mode(GPIO54_nPCE_2_MD);
|
||||
pxa_gpio_mode(GPIO104_pSKTSEL_MD);
|
||||
}
|
||||
|
||||
static void spitz_pcmcia_pwr(struct device *scoop, unsigned short cpr, int nr)
|
||||
{
|
||||
/* Only need to override behaviour for slot 0 */
|
||||
if (nr == 0)
|
||||
spitz_card_pwr_ctrl(SPITZ_PWR_CF, cpr);
|
||||
else
|
||||
write_scoop_reg(scoop, SCOOP_CPR, cpr);
|
||||
}
|
||||
|
||||
static struct scoop_pcmcia_dev spitz_pcmcia_scoop[] = {
|
||||
{
|
||||
.dev = &spitzscoop_device.dev,
|
||||
|
@ -117,6 +177,16 @@ static struct scoop_pcmcia_dev spitz_pcmcia_scoop[] = {
|
|||
},
|
||||
};
|
||||
|
||||
static struct scoop_pcmcia_config spitz_pcmcia_config = {
|
||||
.devs = &spitz_pcmcia_scoop[0],
|
||||
.num_devs = 2,
|
||||
.pcmcia_init = spitz_pcmcia_init,
|
||||
.power_ctrl = spitz_pcmcia_pwr,
|
||||
};
|
||||
|
||||
EXPORT_SYMBOL(spitzscoop_device);
|
||||
EXPORT_SYMBOL(spitzscoop2_device);
|
||||
|
||||
|
||||
/*
|
||||
* Spitz SSP Device
|
||||
|
@ -235,27 +305,14 @@ static int spitz_mci_init(struct device *dev, irqreturn_t (*spitz_detect_int)(in
|
|||
return 0;
|
||||
}
|
||||
|
||||
/* Power control is shared with one of the CF slots so we have a mess */
|
||||
static void spitz_mci_setpower(struct device *dev, unsigned int vdd)
|
||||
{
|
||||
struct pxamci_platform_data* p_d = dev->platform_data;
|
||||
|
||||
unsigned short cpr = read_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR);
|
||||
|
||||
if (( 1 << vdd) & p_d->ocr_mask) {
|
||||
/* printk(KERN_DEBUG "%s: on\n", __FUNCTION__); */
|
||||
set_scoop_gpio(&spitzscoop_device.dev, SPITZ_SCP_CF_POWER);
|
||||
mdelay(2);
|
||||
write_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR, cpr | 0x04);
|
||||
} else {
|
||||
/* printk(KERN_DEBUG "%s: off\n", __FUNCTION__); */
|
||||
write_scoop_reg(&spitzscoop_device.dev, SCOOP_CPR, cpr & ~0x04);
|
||||
|
||||
if (!(cpr | 0x02)) {
|
||||
mdelay(1);
|
||||
reset_scoop_gpio(&spitzscoop_device.dev, SPITZ_SCP_CF_POWER);
|
||||
}
|
||||
}
|
||||
if (( 1 << vdd) & p_d->ocr_mask)
|
||||
spitz_card_pwr_ctrl(SPITZ_PWR_SD, 0x0004);
|
||||
else
|
||||
spitz_card_pwr_ctrl(SPITZ_PWR_SD, 0x0000);
|
||||
}
|
||||
|
||||
static int spitz_mci_get_ro(struct device *dev)
|
||||
|
@ -351,8 +408,8 @@ static void __init common_init(void)
|
|||
|
||||
static void __init spitz_init(void)
|
||||
{
|
||||
scoop_num = 2;
|
||||
scoop_devs = &spitz_pcmcia_scoop[0];
|
||||
platform_scoop_config = &spitz_pcmcia_config;
|
||||
|
||||
spitz_bl_machinfo.set_bl_intensity = spitz_bl_set_intensity;
|
||||
|
||||
common_init();
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue