Merge branch 'smsc911x-armplatforms' of git://github.com/steveglen/linux-2.6
This commit is contained in:
commit
cd02938a82
9
CREDITS
9
CREDITS
|
@ -495,6 +495,11 @@ S: Kopmansg 2
|
|||
S: 411 13 Goteborg
|
||||
S: Sweden
|
||||
|
||||
N: Paul Bristow
|
||||
E: paul@paulbristow.net
|
||||
W: http://paulbristow.net/linux/idefloppy.html
|
||||
D: Maintainer of IDE/ATAPI floppy driver
|
||||
|
||||
N: Dominik Brodowski
|
||||
E: linux@brodo.de
|
||||
W: http://www.brodo.de/
|
||||
|
@ -2642,6 +2647,10 @@ S: C/ Mieses 20, 9-B
|
|||
S: Valladolid 47009
|
||||
S: Spain
|
||||
|
||||
N: Gadi Oxman
|
||||
E: gadio@netvision.net.il
|
||||
D: Original author and maintainer of IDE/ATAPI floppy/tape drivers
|
||||
|
||||
N: Greg Page
|
||||
E: gpage@sovereign.org
|
||||
D: IPX development and support
|
||||
|
|
|
@ -41,6 +41,49 @@ Description:
|
|||
for the device and attempt to bind to it. For example:
|
||||
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
|
||||
|
||||
What: /sys/bus/pci/drivers/.../remove_id
|
||||
Date: February 2009
|
||||
Contact: Chris Wright <chrisw@sous-sol.org>
|
||||
Description:
|
||||
Writing a device ID to this file will remove an ID
|
||||
that was dynamically added via the new_id sysfs entry.
|
||||
The format for the device ID is:
|
||||
VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
|
||||
ID, Subsystem Vendor ID, Subsystem Device ID, Class,
|
||||
and Class Mask. The Vendor ID and Device ID fields are
|
||||
required, the rest are optional. After successfully
|
||||
removing an ID, the driver will no longer support the
|
||||
device. This is useful to ensure auto probing won't
|
||||
match the driver to the device. For example:
|
||||
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
|
||||
|
||||
What: /sys/bus/pci/rescan
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
force a rescan of all PCI buses in the system, and
|
||||
re-discover previously removed devices.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../remove
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
hot-remove the PCI device and any of its children.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../rescan
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
force a rescan of the device's parent bus and all
|
||||
child buses, and re-discover devices removed earlier
|
||||
from this part of the device tree.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../vpd
|
||||
Date: February 2008
|
||||
Contact: Ben Hutchings <bhutchings@solarflare.com>
|
||||
|
@ -52,3 +95,30 @@ Description:
|
|||
that some devices may have malformatted data. If the
|
||||
underlying VPD has a writable section then the
|
||||
corresponding section of this file will be writable.
|
||||
|
||||
What: /sys/bus/pci/devices/.../virtfnN
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when hardware supports the SR-IOV
|
||||
capability and the Physical Function driver has enabled it.
|
||||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Virtual Function whose index is N (0...MaxVFs-1).
|
||||
|
||||
What: /sys/bus/pci/devices/.../dep_link
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when hardware supports the SR-IOV
|
||||
capability and the Physical Function driver has enabled it,
|
||||
and this device has vendor specific dependencies with others.
|
||||
The symbolic link points to the PCI device sysfs entry of
|
||||
Physical Function this device depends on.
|
||||
|
||||
What: /sys/bus/pci/devices/.../physfn
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when a device is a Virtual Function.
|
||||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Physical Function this device associates with.
|
||||
|
|
81
Documentation/ABI/testing/sysfs-fs-ext4
Normal file
81
Documentation/ABI/testing/sysfs-fs-ext4
Normal file
|
@ -0,0 +1,81 @@
|
|||
What: /sys/fs/ext4/<disk>/mb_stats
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Controls whether the multiblock allocator should
|
||||
collect statistics, which are shown during the unmount.
|
||||
1 means to collect statistics, 0 means not to collect
|
||||
statistics
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_group_prealloc
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if the
|
||||
stripe size is not set in the ext4 superblock
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_max_to_scan
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_min_to_scan
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The minimum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_order2_req
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_stream_req
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out of a
|
||||
block group specific preallocation pool, so that small
|
||||
files are packed closely together. Each large file
|
||||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/inode_readahead
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which controls the maximum number of
|
||||
inode table blocks that ext4's inode table readahead
|
||||
algorithm will pre-read into the buffer cache
|
||||
|
||||
What: /sys/fs/ext4/<disk>/delayed_allocation_blocks
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of blocks
|
||||
that are dirty in the page cache, but which do not
|
||||
have their location in the filesystem allocated yet.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/lifetime_write_kbytes
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of kilobytes
|
||||
of data that have been written to this filesystem since it was
|
||||
created.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/session_write_kbytes
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of
|
||||
kilobytes of data that have been written to this
|
||||
filesystem since it was mounted.
|
|
@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple).
|
|||
The return value will be either a pointer to the processor virtual
|
||||
address of the memory, or an error (via PTR_ERR()) if any part of the
|
||||
region is occupied.
|
||||
|
||||
Part III - Debug drivers use of the DMA-API
|
||||
-------------------------------------------
|
||||
|
||||
The DMA-API as described above as some constraints. DMA addresses must be
|
||||
released with the corresponding function with the same size for example. With
|
||||
the advent of hardware IOMMUs it becomes more and more important that drivers
|
||||
do not violate those constraints. In the worst case such a violation can
|
||||
result in data corruption up to destroyed filesystems.
|
||||
|
||||
To debug drivers and find bugs in the usage of the DMA-API checking code can
|
||||
be compiled into the kernel which will tell the developer about those
|
||||
violations. If your architecture supports it you can select the "Enable
|
||||
debugging of DMA-API usage" option in your kernel configuration. Enabling this
|
||||
option has a performance impact. Do not enable it in production kernels.
|
||||
|
||||
If you boot the resulting kernel will contain code which does some bookkeeping
|
||||
about what DMA memory was allocated for which device. If this code detects an
|
||||
error it prints a warning message with some details into your kernel log. An
|
||||
example warning message may look like this:
|
||||
|
||||
------------[ cut here ]------------
|
||||
WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
|
||||
check_unmap+0x203/0x490()
|
||||
Hardware name:
|
||||
forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
|
||||
function [device address=0x00000000640444be] [size=66 bytes] [mapped as
|
||||
single] [unmapped as page]
|
||||
Modules linked in: nfsd exportfs bridge stp llc r8169
|
||||
Pid: 0, comm: swapper Tainted: G W 2.6.28-dmatest-09289-g8bb99c0 #1
|
||||
Call Trace:
|
||||
<IRQ> [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
|
||||
[<ffffffff80647b70>] _spin_unlock+0x10/0x30
|
||||
[<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
|
||||
[<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
|
||||
[<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
|
||||
[<ffffffff80252f96>] queue_work+0x56/0x60
|
||||
[<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
|
||||
[<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
|
||||
[<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
|
||||
[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
|
||||
[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
|
||||
[<ffffffff803c7ea3>] check_unmap+0x203/0x490
|
||||
[<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
|
||||
[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
|
||||
[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
|
||||
[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
|
||||
[<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
|
||||
[<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
|
||||
[<ffffffff8020c093>] ret_from_intr+0x0/0xa
|
||||
<EOI> <4>---[ end trace f6435a98e2a38c0e ]---
|
||||
|
||||
The driver developer can find the driver and the device including a stacktrace
|
||||
of the DMA-API call which caused this warning.
|
||||
|
||||
Per default only the first error will result in a warning message. All other
|
||||
errors will only silently counted. This limitation exist to prevent the code
|
||||
from flooding your kernel log. To support debugging a device driver this can
|
||||
be disabled via debugfs. See the debugfs interface documentation below for
|
||||
details.
|
||||
|
||||
The debugfs directory for the DMA-API debugging code is called dma-api/. In
|
||||
this directory the following files can currently be found:
|
||||
|
||||
dma-api/all_errors This file contains a numeric value. If this
|
||||
value is not equal to zero the debugging code
|
||||
will print a warning for every error it finds
|
||||
into the kernel log. Be carefull with this
|
||||
option. It can easily flood your logs.
|
||||
|
||||
dma-api/disabled This read-only file contains the character 'Y'
|
||||
if the debugging code is disabled. This can
|
||||
happen when it runs out of memory or if it was
|
||||
disabled at boot time
|
||||
|
||||
dma-api/error_count This file is read-only and shows the total
|
||||
numbers of errors found.
|
||||
|
||||
dma-api/num_errors The number in this file shows how many
|
||||
warnings will be printed to the kernel log
|
||||
before it stops. This number is initialized to
|
||||
one at system boot and be set by writing into
|
||||
this file
|
||||
|
||||
dma-api/min_free_entries
|
||||
This read-only file can be read to get the
|
||||
minimum number of free dma_debug_entries the
|
||||
allocator has ever seen. If this value goes
|
||||
down to zero the code will disable itself
|
||||
because it is not longer reliable.
|
||||
|
||||
dma-api/num_free_entries
|
||||
The current number of free dma_debug_entries
|
||||
in the allocator.
|
||||
|
||||
If you have this code compiled into your kernel it will be enabled by default.
|
||||
If you want to boot without the bookkeeping anyway you can provide
|
||||
'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
|
||||
Notice that you can not enable it again at runtime. You have to reboot to do
|
||||
so.
|
||||
|
||||
When the code disables itself at runtime this is most likely because it ran
|
||||
out of dma_debug_entries. These entries are preallocated at boot. The number
|
||||
of preallocated entries is defined per architecture. If it is too low for you
|
||||
boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
|
||||
architectural default.
|
||||
|
|
|
@ -199,6 +199,7 @@ X!Edrivers/pci/hotplug.c
|
|||
-->
|
||||
!Edrivers/pci/probe.c
|
||||
!Edrivers/pci/rom.c
|
||||
!Edrivers/pci/iov.c
|
||||
</sect1>
|
||||
<sect1><title>PCI Hotplug Support Library</title>
|
||||
!Edrivers/pci/hotplug/pci_hotplug_core.c
|
||||
|
|
|
@ -117,9 +117,6 @@ static int __init init_procfs_example(void)
|
|||
rv = -ENOMEM;
|
||||
goto out;
|
||||
}
|
||||
|
||||
example_dir->owner = THIS_MODULE;
|
||||
|
||||
/* create jiffies using convenience function */
|
||||
jiffies_file = create_proc_read_entry("jiffies",
|
||||
0444, example_dir,
|
||||
|
@ -130,8 +127,6 @@ static int __init init_procfs_example(void)
|
|||
goto no_jiffies;
|
||||
}
|
||||
|
||||
jiffies_file->owner = THIS_MODULE;
|
||||
|
||||
/* create foo and bar files using same callback
|
||||
* functions
|
||||
*/
|
||||
|
@ -146,7 +141,6 @@ static int __init init_procfs_example(void)
|
|||
foo_file->data = &foo_data;
|
||||
foo_file->read_proc = proc_read_foobar;
|
||||
foo_file->write_proc = proc_write_foobar;
|
||||
foo_file->owner = THIS_MODULE;
|
||||
|
||||
bar_file = create_proc_entry("bar", 0644, example_dir);
|
||||
if(bar_file == NULL) {
|
||||
|
@ -159,7 +153,6 @@ static int __init init_procfs_example(void)
|
|||
bar_file->data = &bar_data;
|
||||
bar_file->read_proc = proc_read_foobar;
|
||||
bar_file->write_proc = proc_write_foobar;
|
||||
bar_file->owner = THIS_MODULE;
|
||||
|
||||
/* create symlink */
|
||||
symlink = proc_symlink("jiffies_too", example_dir,
|
||||
|
@ -169,8 +162,6 @@ static int __init init_procfs_example(void)
|
|||
goto no_symlink;
|
||||
}
|
||||
|
||||
symlink->owner = THIS_MODULE;
|
||||
|
||||
/* everything OK */
|
||||
printk(KERN_INFO "%s %s initialised\n",
|
||||
MODULE_NAME, MODULE_VERS);
|
||||
|
|
|
@ -4,506 +4,356 @@
|
|||
Revised Feb 12, 2004 by Martine Silbermann
|
||||
email: Martine.Silbermann@hp.com
|
||||
Revised Jun 25, 2004 by Tom L Nguyen
|
||||
Revised Jul 9, 2008 by Matthew Wilcox <willy@linux.intel.com>
|
||||
Copyright 2003, 2008 Intel Corporation
|
||||
|
||||
1. About this guide
|
||||
|
||||
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 (FAQ) section.
|
||||
This guide describes the basics of Message Signaled Interrupts (MSIs),
|
||||
the advantages of using MSI over traditional interrupt mechanisms, how
|
||||
to change your driver to use MSI or MSI-X and some basic diagnostics to
|
||||
try if a device doesn't support MSIs.
|
||||
|
||||
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. What are MSIs?
|
||||
|
||||
2. Copyright 2003 Intel Corporation
|
||||
A Message Signaled Interrupt is a write from the device to a special
|
||||
address which causes an interrupt to be received by the CPU.
|
||||
|
||||
3. What is MSI/MSI-X?
|
||||
The MSI capability was first specified in PCI 2.2 and was later enhanced
|
||||
in PCI 3.0 to allow each interrupt to be masked individually. The MSI-X
|
||||
capability was also introduced with PCI 3.0. It supports more interrupts
|
||||
per device than MSI and allows interrupts to be independently configured.
|
||||
|
||||
Message Signaled Interrupt (MSI), as described in the PCI Local Bus
|
||||
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
|
||||
generated in the form of a Memory Write, all transaction conditions,
|
||||
such as a Retry, Master-Abort, Target-Abort or normal completion, are
|
||||
supported.
|
||||
Devices may support both MSI and MSI-X, but only one can be enabled at
|
||||
a time.
|
||||
|
||||
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
|
||||
responsible for initializing the message address and message data of
|
||||
the device function's MSI/MSI-X capability structure during device
|
||||
initial configuration.
|
||||
|
||||
An MSI capable device function indicates MSI support by implementing
|
||||
the MSI/MSI-X capability structure in its PCI capability list. The
|
||||
device function may implement both the MSI capability structure and
|
||||
the MSI-X capability structure; however, the bus driver should not
|
||||
enable both.
|
||||
3. Why use MSIs?
|
||||
|
||||
The MSI capability structure contains Message Control register,
|
||||
Message Address register and Message Data register. These registers
|
||||
provide the bus driver control over MSI. The Message Control register
|
||||
indicates the MSI capability supported by the device. The Message
|
||||
Address register specifies the target address and the Message Data
|
||||
register specifies the characteristics of the message. To request
|
||||
service, the device function writes the content of the Message Data
|
||||
register to the target address. The device and its software driver
|
||||
are prohibited from writing to these registers.
|
||||
There are three reasons why using MSIs can give an advantage over
|
||||
traditional pin-based interrupts.
|
||||
|
||||
The MSI-X capability structure is an optional extension to MSI. It
|
||||
uses an independent and separate capability structure. There are
|
||||
some key advantages to implementing the MSI-X capability structure
|
||||
over the MSI capability structure as described below.
|
||||
Pin-based PCI interrupts are often shared amongst several devices.
|
||||
To support this, the kernel must call each interrupt handler associated
|
||||
with an interrupt, which leads to reduced performance for the system as
|
||||
a whole. MSIs are never shared, so this problem cannot arise.
|
||||
|
||||
- Support a larger maximum number of vectors per function.
|
||||
When a device writes data to memory, then raises a pin-based interrupt,
|
||||
it is possible that the interrupt may arrive before all the data has
|
||||
arrived in memory (this becomes more likely with devices behind PCI-PCI
|
||||
bridges). In order to ensure that all the data has arrived in memory,
|
||||
the interrupt handler must read a register on the device which raised
|
||||
the interrupt. PCI transaction ordering rules require that all the data
|
||||
arrives in memory before the value can be returned from the register.
|
||||
Using MSIs avoids this problem as the interrupt-generating write cannot
|
||||
pass the data writes, so by the time the interrupt is raised, the driver
|
||||
knows that all the data has arrived in memory.
|
||||
|
||||
- Provide the ability for system software to configure
|
||||
each vector with an independent message address and message
|
||||
data, specified by a table that resides in Memory Space.
|
||||
PCI devices can only support a single pin-based interrupt per function.
|
||||
Often drivers have to query the device to find out what event has
|
||||
occurred, slowing down interrupt handling for the common case. With
|
||||
MSIs, a device can support more interrupts, allowing each interrupt
|
||||
to be specialised to a different purpose. One possible design gives
|
||||
infrequent conditions (such as errors) their own interrupt which allows
|
||||
the driver to handle the normal interrupt handling path more efficiently.
|
||||
Other possible designs include giving one interrupt to each packet queue
|
||||
in a network card or each port in a storage controller.
|
||||
|
||||
- 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 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?
|
||||
4. How to use MSIs
|
||||
|
||||
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.
|
||||
PCI devices are initialised to use pin-based interrupts. The device
|
||||
driver has to set up the device to use MSI or MSI-X. Not all machines
|
||||
support MSIs correctly, and for those machines, the APIs described below
|
||||
will simply fail and the device will continue to use pin-based interrupts.
|
||||
|
||||
Due to increasing pressure on chipset and processor packages to
|
||||
reduce pin count, the need for interrupt pins is expected to
|
||||
diminish over time. Devices, due to pin constraints, may implement
|
||||
messages to increase performance.
|
||||
4.1 Include kernel support for MSIs
|
||||
|
||||
PCI Express endpoints uses INTx emulation (in-band messages) instead
|
||||
of IRQ pin assertion. Using INTx emulation requires interrupt
|
||||
sharing among devices connected to the same node (PCI bridge) while
|
||||
MSI is unique (non-shared) and does not require BIOS configuration
|
||||
support. As a result, the PCI Express technology requires MSI
|
||||
support for better interrupt performance.
|
||||
To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI
|
||||
option enabled. This option is only available on some architectures,
|
||||
and it may depend on some other options also being set. For example,
|
||||
on x86, you must also enable X86_UP_APIC or SMP in order to see the
|
||||
CONFIG_PCI_MSI option.
|
||||
|
||||
Using MSI enables the device functions to support two or more
|
||||
vectors, which can be configured to target different CPUs to
|
||||
increase scalability.
|
||||
4.2 Using MSI
|
||||
|
||||
5. Configuring a driver to use MSI/MSI-X
|
||||
Most of the hard work is done for the driver in the PCI layer. It simply
|
||||
has to request that the PCI layer set up the MSI capability for this
|
||||
device.
|
||||
|
||||
By default, the kernel will not enable MSI/MSI-X on all devices that
|
||||
support this capability. The CONFIG_PCI_MSI kernel option
|
||||
must be selected to enable MSI/MSI-X support.
|
||||
|
||||
5.1 Including MSI/MSI-X support into the kernel
|
||||
|
||||
To allow MSI/MSI-X capable device drivers to selectively enable
|
||||
MSI/MSI-X (using pci_enable_msi()/pci_enable_msix() as described
|
||||
below), the VECTOR based scheme needs to be enabled by setting
|
||||
CONFIG_PCI_MSI during kernel config.
|
||||
|
||||
Since the target of the inbound message is the local APIC, providing
|
||||
CONFIG_X86_LOCAL_APIC must be enabled as well as CONFIG_PCI_MSI.
|
||||
|
||||
5.2 Configuring for MSI support
|
||||
|
||||
Due to the non-contiguous fashion in vector assignment of the
|
||||
existing Linux kernel, this version does not support multiple
|
||||
messages regardless of a device function is capable of supporting
|
||||
more than one vector. To enable MSI on a device function's MSI
|
||||
capability structure requires a device driver to call the function
|
||||
pci_enable_msi() explicitly.
|
||||
|
||||
5.2.1 API pci_enable_msi
|
||||
4.2.1 pci_enable_msi
|
||||
|
||||
int pci_enable_msi(struct pci_dev *dev)
|
||||
|
||||
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 a conflict
|
||||
of the new assigned vector with existing pre-assigned vector requires
|
||||
a device driver to call this API before calling request_irq().
|
||||
A successful call will allocate ONE interrupt to the device, regardless
|
||||
of how many MSIs the device supports. The device will be switched from
|
||||
pin-based interrupt mode to MSI mode. The dev->irq number is changed
|
||||
to a new number which represents the message signaled interrupt.
|
||||
This function should be called before the driver calls request_irq()
|
||||
since enabling MSIs disables the pin-based IRQ and the driver will not
|
||||
receive interrupts on the old interrupt.
|
||||
|
||||
5.2.2 API pci_disable_msi
|
||||
4.2.2 pci_enable_msi_block
|
||||
|
||||
int pci_enable_msi_block(struct pci_dev *dev, int count)
|
||||
|
||||
This variation on the above call allows a device driver to request multiple
|
||||
MSIs. The MSI specification only allows interrupts to be allocated in
|
||||
powers of two, up to a maximum of 2^5 (32).
|
||||
|
||||
If this function returns 0, it has succeeded in allocating at least as many
|
||||
interrupts as the driver requested (it may have allocated more in order
|
||||
to satisfy the power-of-two requirement). In this case, the function
|
||||
enables MSI on this device and updates dev->irq to be the lowest of
|
||||
the new interrupts assigned to it. The other interrupts assigned to
|
||||
the device are in the range dev->irq to dev->irq + count - 1.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device. If this function returns a positive number, it will be
|
||||
less than 'count' and indicate the number of interrupts that could have
|
||||
been allocated. In neither case will the irq value have been
|
||||
updated, nor will the device have been switched into MSI mode.
|
||||
|
||||
The device driver must decide what action to take if
|
||||
pci_enable_msi_block() returns a value less than the number asked for.
|
||||
Some devices can make use of fewer interrupts than the maximum they
|
||||
request; in this case the driver should call pci_enable_msi_block()
|
||||
again. Note that it is not guaranteed to succeed, even when the
|
||||
'count' has been reduced to the value returned from a previous call to
|
||||
pci_enable_msi_block(). This is because there are multiple constraints
|
||||
on the number of vectors that can be allocated; pci_enable_msi_block()
|
||||
will return as soon as it finds any constraint that doesn't allow the
|
||||
call to succeed.
|
||||
|
||||
4.2.3 pci_disable_msi
|
||||
|
||||
void pci_disable_msi(struct pci_dev *dev)
|
||||
|
||||
This API should always be used to undo the effect of pci_enable_msi()
|
||||
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.
|
||||
This function should be used to undo the effect of pci_enable_msi() or
|
||||
pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
|
||||
interrupt number and frees the previously allocated message signaled
|
||||
interrupt(s). The interrupt may subsequently be assigned to another
|
||||
device, so drivers should not cache the value of dev->irq.
|
||||
|
||||
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.
|
||||
A device driver must always call free_irq() on the interrupt(s)
|
||||
for which it has called request_irq() before calling this function.
|
||||
Failure to do so will result in a BUG_ON(), the device will be left with
|
||||
MSI enabled and will leak its vector.
|
||||
|
||||
5.2.3 MSI mode vs. legacy mode diagram
|
||||
4.3 Using MSI-X
|
||||
|
||||
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.
|
||||
|
||||
------------ pci_enable_msi ------------------------
|
||||
| | <=============== | |
|
||||
| MSI MODE | | PIN-IRQ ASSERTION MODE |
|
||||
| | ===============> | |
|
||||
------------ pci_disable_msi ------------------------
|
||||
|
||||
|
||||
Figure 1. MSI Mode vs. Legacy Mode
|
||||
|
||||
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
|
||||
stored in dev->irq will be saved by the PCI subsystem and a new
|
||||
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 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 the released
|
||||
MSI vector as unused.
|
||||
|
||||
Once being marked as unused, there is no guarantee that the PCI
|
||||
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-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.
|
||||
|
||||
5.3 Configuring for MSI-X support
|
||||
|
||||
Due to the ability of the system software to configure each vector of
|
||||
the MSI-X capability structure with an independent message address
|
||||
and message data, the non-contiguous fashion in vector assignment of
|
||||
the existing Linux kernel has no impact on supporting multiple
|
||||
messages on an MSI-X capable device functions. To enable MSI-X on
|
||||
a device function's MSI-X capability structure requires its device
|
||||
driver to call the function pci_enable_msix() explicitly.
|
||||
|
||||
The function pci_enable_msix(), once invoked, enables either
|
||||
all or nothing, depending on the current availability of PCI vector
|
||||
resources. If the PCI vector resources are available for the number
|
||||
of vectors requested by a device driver, this function will configure
|
||||
the MSI-X table of the MSI-X capability structure of a device with
|
||||
requested messages. To emphasize this reason, for example, a device
|
||||
may be capable for supporting the maximum of 32 vectors while its
|
||||
software driver usually may request 4 vectors. It is recommended
|
||||
that the device driver should call this function once during the
|
||||
initialization phase of the device driver.
|
||||
|
||||
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 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 in unpredictable behavior.
|
||||
|
||||
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
|
||||
interrupt service handler or each vector with a unique interrupt
|
||||
service handler.
|
||||
|
||||
5.3.1 Handling MMIO address space of MSI-X Table
|
||||
|
||||
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 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 (Pending Bit Array) and MMIO address space of the MSI-X
|
||||
table/MSI-X PBA. A device driver should not access the MMIO address
|
||||
space of the MSI-X table/MSI-X PBA.
|
||||
|
||||
5.3.2 API pci_enable_msix
|
||||
|
||||
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
|
||||
to enable MSI-X messages on its hardware device. Depending on
|
||||
the availability of PCI vectors resources, the PCI subsystem enables
|
||||
either all or none of the requested vectors.
|
||||
|
||||
Argument 'dev' points to the device (pci_dev) structure.
|
||||
|
||||
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:
|
||||
The MSI-X capability is much more flexible than the MSI capability.
|
||||
It supports up to 2048 interrupts, each of which can be controlled
|
||||
independently. To support this flexibility, drivers must use an array of
|
||||
`struct msix_entry':
|
||||
|
||||
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 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 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 for keeping track of allocated MSI-X
|
||||
vectors in its internal data structure.
|
||||
This allows for the device to use these interrupts in a sparse fashion;
|
||||
for example it could use interrupts 3 and 1027 and allocate only a
|
||||
two-element array. The driver is expected to fill in the 'entry' value
|
||||
in each element of the array to indicate which entries it wants the kernel
|
||||
to assign interrupts for. It is invalid to fill in two entries with the
|
||||
same number.
|
||||
|
||||
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
|
||||
specified in second argument, or a result of no available vector,
|
||||
or a result of failing to initialize MSI-X table entries.
|
||||
4.3.1 pci_enable_msix
|
||||
|
||||
5.3.3 API pci_disable_msix
|
||||
int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
|
||||
|
||||
Calling this function asks the PCI subsystem to allocate 'nvec' MSIs.
|
||||
The 'entries' argument is a pointer to an array of msix_entry structs
|
||||
which should be at least 'nvec' entries in size. On success, the
|
||||
function will return 0 and the device will have been switched into
|
||||
MSI-X interrupt mode. The 'vector' elements in each entry will have
|
||||
been filled in with the interrupt number. The driver should then call
|
||||
request_irq() for each 'vector' that it decides to use.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to allocate any more MSI-X interrupts for
|
||||
this device. If it returns a positive number, it indicates the maximum
|
||||
number of interrupt vectors that could have been allocated. See example
|
||||
below.
|
||||
|
||||
This function, in contrast with pci_enable_msi(), does not adjust
|
||||
dev->irq. The device will not generate interrupts for this interrupt
|
||||
number once MSI-X is enabled. The device driver is responsible for
|
||||
keeping track of the interrupts assigned to the MSI-X vectors so it can
|
||||
free them again later.
|
||||
|
||||
Device drivers should normally call this function once per device
|
||||
during the initialization phase.
|
||||
|
||||
It is ideal if drivers can cope with a variable number of MSI-X interrupts,
|
||||
there are many reasons why the platform may not be able to provide the
|
||||
exact number a driver asks for.
|
||||
|
||||
A request loop to achieve that might look like:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
|
||||
rc = pci_enable_msix(adapter->pdev,
|
||||
adapter->msix_entries, nvec);
|
||||
if (rc > 0)
|
||||
nvec = rc;
|
||||
else
|
||||
return rc;
|
||||
}
|
||||
|
||||
return -ENOSPC;
|
||||
}
|
||||
|
||||
4.3.2 pci_disable_msix
|
||||
|
||||
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 in a BUG_ON() and
|
||||
a device will be left with MSI-X enabled and leaks its vectors.
|
||||
This API should be used to undo the effect of pci_enable_msix(). It frees
|
||||
the previously allocated message signaled interrupts. The interrupts may
|
||||
subsequently be assigned to another device, so drivers should not cache
|
||||
the value of the 'vector' elements over a call to pci_disable_msix().
|
||||
|
||||
5.3.4 MSI-X mode vs. legacy mode diagram
|
||||
A device driver must always call free_irq() on the interrupt(s)
|
||||
for which it has called request_irq() before calling this function.
|
||||
Failure to do so will result in a BUG_ON(), the device will be left with
|
||||
MSI enabled and will leak its vector.
|
||||
|
||||
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).
|
||||
4.3.3 The MSI-X Table
|
||||
|
||||
------------ pci_enable_msix(,,n) ------------------------
|
||||
| | <=============== | |
|
||||
| MSI-X MODE | | PIN-IRQ ASSERTION MODE |
|
||||
| | ===============> | |
|
||||
------------ pci_disable_msix ------------------------
|
||||
The MSI-X capability specifies a BAR and offset within that BAR for the
|
||||
MSI-X Table. This address is mapped by the PCI subsystem, and should not
|
||||
be accessed directly by the device driver. If the driver wishes to
|
||||
mask or unmask an interrupt, it should call disable_irq() / enable_irq().
|
||||
|
||||
Figure 2. MSI-X Mode vs. Legacy Mode
|
||||
4.4 Handling devices implementing both MSI and MSI-X capabilities
|
||||
|
||||
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
|
||||
specified in second argument.
|
||||
If a device implements both MSI and MSI-X capabilities, it can
|
||||
run in either MSI mode or MSI-X mode but not both simultaneously.
|
||||
This is a requirement of the PCI spec, and it is enforced by the
|
||||
PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or
|
||||
pci_enable_msix() when MSI is already enabled will result in an error.
|
||||
If a device driver wishes to switch between MSI and MSI-X at runtime,
|
||||
it must first quiesce the device, then switch it back to pin-interrupt
|
||||
mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
|
||||
operation. This is not expected to be a common operation but may be
|
||||
useful for debugging or testing during development.
|
||||
|
||||
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 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.
|
||||
4.5 Considerations when using MSIs
|
||||
|
||||
Once being marked as unused, there is no guarantee that the PCI
|
||||
subsystem will reserve these MSI-X vectors for a device. Depending on
|
||||
the availability of current PCI vector resources and the number of
|
||||
MSI/MSI-X requests from other drivers, these MSI-X vectors may be
|
||||
re-assigned.
|
||||
4.5.1 Choosing between MSI-X and MSI
|
||||
|
||||
For the case where the PCI subsystem re-assigned these MSI-X vectors
|
||||
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.
|
||||
If your device supports both MSI-X and MSI capabilities, you should use
|
||||
the MSI-X facilities in preference to the MSI facilities. As mentioned
|
||||
above, MSI-X supports any number of interrupts between 1 and 2048.
|
||||
In constrast, MSI is restricted to a maximum of 32 interrupts (and
|
||||
must be a power of two). In addition, the MSI interrupt vectors must
|
||||
be allocated consecutively, so the system may not be able to allocate
|
||||
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
|
||||
interrupts must all be targetted at the same set of CPUs whereas MSI-X
|
||||
interrupts can all be targetted at different CPUs.
|
||||
|
||||
5.4 Handling function implementing both MSI and MSI-X capabilities
|
||||
4.5.2 Spinlocks
|
||||
|
||||
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 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.
|
||||
Most device drivers have a per-device spinlock which is taken in the
|
||||
interrupt handler. With pin-based interrupts or a single MSI, it is not
|
||||
necessary to disable interrupts (Linux guarantees the same interrupt will
|
||||
not be re-entered). If a device uses multiple interrupts, the driver
|
||||
must disable interrupts while the lock is held. If the device sends
|
||||
a different interrupt, the driver will deadlock trying to recursively
|
||||
acquire the spinlock.
|
||||
|
||||
5.5 Hardware requirements for MSI/MSI-X support
|
||||
There are two solutions. The first is to take the lock with
|
||||
spin_lock_irqsave() or spin_lock_irq() (see
|
||||
Documentation/DocBook/kernel-locking). The second is to specify
|
||||
IRQF_DISABLED to request_irq() so that the kernel runs the entire
|
||||
interrupt routine with interrupts disabled.
|
||||
|
||||
MSI/MSI-X support requires support from both system hardware and
|
||||
individual hardware device functions.
|
||||
If your MSI interrupt routine does not hold the lock for the whole time
|
||||
it is running, the first solution may be best. The second solution is
|
||||
normally preferred as it avoids making two transitions from interrupt
|
||||
disabled to enabled and back again.
|
||||
|
||||
5.5.1 Required x86 hardware support
|
||||
4.6 How to tell whether MSI/MSI-X is enabled on a device
|
||||
|
||||
Since the target of MSI address is the local APIC CPU, enabling
|
||||
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.
|
||||
Using 'lspci -v' (as root) may show some devices with "MSI", "Message
|
||||
Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities
|
||||
has an 'Enable' flag which will be followed with either "+" (enabled)
|
||||
or "-" (disabled).
|
||||
|
||||
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.
|
||||
|
||||
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 platforms.
|
||||
5. MSI quirks
|
||||
|
||||
5.5.2 Device hardware support
|
||||
Several PCI chipsets or devices are known not to support MSIs.
|
||||
The PCI stack provides three ways to disable MSIs:
|
||||
|
||||
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 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 initialized the MSI/MSI-X capability structure of the
|
||||
device function. The device function is now running on MSI/MSI-X mode.
|
||||
1. globally
|
||||
2. on all devices behind a specific bridge
|
||||
3. on a single device
|
||||
|
||||
5.6 How to tell whether MSI/MSI-X is enabled on device function
|
||||
5.1. Disabling MSIs globally
|
||||
|
||||
At the driver level, a return of zero from the function call of
|
||||
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.
|
||||
Some host chipsets simply don't support MSIs properly. If we're
|
||||
lucky, the manufacturer knows this and has indicated it in the ACPI
|
||||
FADT table. In this case, Linux will automatically disable MSIs.
|
||||
Some boards don't include this information in the table and so we have
|
||||
to detect them ourselves. The complete list of these is found near the
|
||||
quirk_disable_all_msi() function in drivers/pci/quirks.c.
|
||||
|
||||
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.
|
||||
If you have a board which has problems with MSIs, you can pass pci=nomsi
|
||||
on the kernel command line to disable MSIs on all devices. It would be
|
||||
in your best interests to report the problem to linux-pci@vger.kernel.org
|
||||
including a full 'lspci -v' so we can add the quirks to the kernel.
|
||||
|
||||
CPU0 CPU1
|
||||
0: 324639 0 IO-APIC-edge timer
|
||||
1: 1186 0 IO-APIC-edge i8042
|
||||
2: 0 0 XT-PIC cascade
|
||||
12: 2797 0 IO-APIC-edge i8042
|
||||
14: 6543 0 IO-APIC-edge ide0
|
||||
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
|
||||
225: 30 0 IO-APIC-level aic7xxx
|
||||
233: 30 0 IO-APIC-level aic7xxx
|
||||
NMI: 0 0
|
||||
LOC: 324553 325068
|
||||
ERR: 0
|
||||
MIS: 0
|
||||
5.2. Disabling MSIs below a bridge
|
||||
|
||||
6. MSI quirks
|
||||
Some PCI bridges are not able to route MSIs between busses properly.
|
||||
In this case, MSIs must be disabled on all devices behind the bridge.
|
||||
|
||||
Several PCI chipsets or devices are known to not support MSI.
|
||||
The PCI stack provides 3 possible levels of MSI disabling:
|
||||
* on a single device
|
||||
* on all devices behind a specific bridge
|
||||
* globally
|
||||
Some bridges allow you to enable MSIs by changing some bits in their
|
||||
PCI configuration space (especially the Hypertransport chipsets such
|
||||
as the nVidia nForce and Serverworks HT2000). As with host chipsets,
|
||||
Linux mostly knows about them and automatically enables MSIs if it can.
|
||||
If you have a bridge which Linux doesn't yet know about, you can enable
|
||||
MSIs in configuration space using whatever method you know works, then
|
||||
enable MSIs on that bridge by doing:
|
||||
|
||||
6.1. Disabling MSI on a single device
|
||||
echo 1 > /sys/bus/pci/devices/$bridge/msi_bus
|
||||
|
||||
Under some circumstances it might be required to disable MSI on a
|
||||
single device. This may be achieved by either not calling pci_enable_msi()
|
||||
or all, or setting the pci_dev->no_msi flag before (most of the time
|
||||
in a quirk).
|
||||
where $bridge is the PCI address of the bridge you've enabled (eg
|
||||
0000:00:0e.0).
|
||||
|
||||
6.2. Disabling MSI below a bridge
|
||||
To disable MSIs, echo 0 instead of 1. Changing this value should be
|
||||
done with caution as it can break interrupt handling for all devices
|
||||
below this bridge.
|
||||
|
||||
The vast majority of MSI quirks are required by PCI bridges not
|
||||
being able to route MSI between busses. In this case, MSI have to be
|
||||
disabled on all devices behind this bridge. It is achieves by setting
|
||||
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
|
||||
subordinate bus. There is no need to set the same flag on bridges that
|
||||
are below the broken bridge. When pci_enable_msi() is called to enable
|
||||
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
|
||||
flag in all parent busses of the device.
|
||||
Again, please notify linux-pci@vger.kernel.org of any bridges that need
|
||||
special handling.
|
||||
|
||||
Some bridges actually support dynamic MSI support enabling/disabling
|
||||
by changing some bits in their PCI configuration space (especially
|
||||
the Hypertransport chipsets such as the nVidia nForce and Serverworks
|
||||
HT2000). It may then be required to update the NO_MSI flag on the
|
||||
corresponding devices in the sysfs hierarchy. To enable MSI support
|
||||
on device "0000:00:0e", do:
|
||||
5.3. Disabling MSIs on a single device
|
||||
|
||||
echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus
|
||||
Some devices are known to have faulty MSI implementations. Usually this
|
||||
is handled in the individual device driver but occasionally it's necessary
|
||||
to handle this with a quirk. Some drivers have an option to disable use
|
||||
of MSI. While this is a convenient workaround for the driver author,
|
||||
it is not good practise, and should not be emulated.
|
||||
|
||||
To disable MSI support, echo 0 instead of 1. Note that it should be
|
||||
used with caution since changing this value might break interrupts.
|
||||
5.4. Finding why MSIs are disabled on a device
|
||||
|
||||
6.3. Disabling MSI globally
|
||||
From the above three sections, you can see that there are many reasons
|
||||
why MSIs may not be enabled for a given device. Your first step should
|
||||
be to examine your dmesg carefully to determine whether MSIs are enabled
|
||||
for your machine. You should also check your .config to be sure you
|
||||
have enabled CONFIG_PCI_MSI.
|
||||
|
||||
Some extreme cases may require to disable MSI globally on the system.
|
||||
For now, the only known case is a Serverworks PCI-X chipsets (MSI are
|
||||
not supported on several busses that are not all connected to the
|
||||
chipset in the Linux PCI hierarchy). In the vast majority of other
|
||||
cases, disabling only behind a specific bridge is enough.
|
||||
Then, 'lspci -t' gives the list of bridges above a device. Reading
|
||||
/sys/bus/pci/devices/*/msi_bus will tell you whether MSI are enabled (1)
|
||||
or disabled (0). If 0 is found in any of the msi_bus files belonging
|
||||
to bridges between the PCI root and the device, MSIs are disabled.
|
||||
|
||||
For debugging purpose, the user may also pass pci=nomsi on the kernel
|
||||
command-line to explicitly disable MSI globally. But, once the appro-
|
||||
priate quirks are added to the kernel, this option should not be
|
||||
required anymore.
|
||||
|
||||
6.4. Finding why MSI cannot be enabled on a device
|
||||
|
||||
Assuming that MSI are not enabled on a device, you should look at
|
||||
dmesg to find messages that quirks may output when disabling MSI
|
||||
on some devices, some bridges or even globally.
|
||||
Then, lspci -t gives the list of bridges above a device. Reading
|
||||
/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
|
||||
are enabled (1) or disabled (0). In 0 is found in a single bridge
|
||||
msi_bus file above the device, MSI cannot be enabled.
|
||||
|
||||
7. FAQ
|
||||
|
||||
Q1. Are there any limitations on using the MSI?
|
||||
|
||||
A1. If the PCI device supports MSI and conforms to the
|
||||
specification and the platform supports the APIC local bus,
|
||||
then using MSI should work.
|
||||
|
||||
Q2. Will it work on all the Pentium processors (P3, P4, Xeon,
|
||||
AMD processors)? In P3 IPI's are transmitted on the APIC local
|
||||
bus and in P4 and Xeon they are transmitted on the system
|
||||
bus. Are there any implications with this?
|
||||
|
||||
A2. MSI support enables a PCI device sending an inbound
|
||||
memory write (0xfeexxxxx as target address) on its PCI bus
|
||||
directly to the FSB. Since the message address has a
|
||||
redirection hint bit cleared, it should work.
|
||||
|
||||
Q3. The target address 0xfeexxxxx will be translated by the
|
||||
Host Bridge into an interrupt message. Are there any
|
||||
limitations on the chipsets such as Intel 8xx, Intel e7xxx,
|
||||
or VIA?
|
||||
|
||||
A3. If these chipsets support an inbound memory write with
|
||||
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 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,
|
||||
Master-Abort, Target-Abort, or normal completion) are
|
||||
supported. A device sending an MSI must abide by all the PCI
|
||||
rules and conditions regarding that inbound memory write. So,
|
||||
if a retry is signaled it must retry, etc... We believe that
|
||||
the recommendation for Abort is also a retry (refer to PCI
|
||||
specification 2.3 or latest).
|
||||
It is also worth checking the device driver to see whether it supports MSIs.
|
||||
For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
|
||||
pci_enable_msi_block().
|
||||
|
|
99
Documentation/PCI/pci-iov-howto.txt
Normal file
99
Documentation/PCI/pci-iov-howto.txt
Normal file
|
@ -0,0 +1,99 @@
|
|||
PCI Express I/O Virtualization Howto
|
||||
Copyright (C) 2009 Intel Corporation
|
||||
Yu Zhao <yu.zhao@intel.com>
|
||||
|
||||
|
||||
1. Overview
|
||||
|
||||
1.1 What is SR-IOV
|
||||
|
||||
Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended
|
||||
capability which makes one physical device appear as multiple virtual
|
||||
devices. The physical device is referred to as Physical Function (PF)
|
||||
while the virtual devices are referred to as Virtual Functions (VF).
|
||||
Allocation of the VF can be dynamically controlled by the PF via
|
||||
registers encapsulated in the capability. By default, this feature is
|
||||
not enabled and the PF behaves as traditional PCIe device. Once it's
|
||||
turned on, each VF's PCI configuration space can be accessed by its own
|
||||
Bus, Device and Function Number (Routing ID). And each VF also has PCI
|
||||
Memory Space, which is used to map its register set. VF device driver
|
||||
operates on the register set so it can be functional and appear as a
|
||||
real existing PCI device.
|
||||
|
||||
2. User Guide
|
||||
|
||||
2.1 How can I enable SR-IOV capability
|
||||
|
||||
The device driver (PF driver) will control the enabling and disabling
|
||||
of the capability via API provided by SR-IOV core. If the hardware
|
||||
has SR-IOV capability, loading its PF driver would enable it and all
|
||||
VFs associated with the PF.
|
||||
|
||||
2.2 How can I use the Virtual Functions
|
||||
|
||||
The VF is treated as hot-plugged PCI devices in the kernel, so they
|
||||
should be able to work in the same way as real PCI devices. The VF
|
||||
requires device driver that is same as a normal PCI device's.
|
||||
|
||||
3. Developer Guide
|
||||
|
||||
3.1 SR-IOV API
|
||||
|
||||
To enable SR-IOV capability:
|
||||
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
|
||||
'nr_virtfn' is number of VFs to be enabled.
|
||||
|
||||
To disable SR-IOV capability:
|
||||
void pci_disable_sriov(struct pci_dev *dev);
|
||||
|
||||
To notify SR-IOV core of Virtual Function Migration:
|
||||
irqreturn_t pci_sriov_migration(struct pci_dev *dev);
|
||||
|
||||
3.2 Usage example
|
||||
|
||||
Following piece of code illustrates the usage of the SR-IOV API.
|
||||
|
||||
static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
|
||||
{
|
||||
pci_enable_sriov(dev, NR_VIRTFN);
|
||||
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void __devexit dev_remove(struct pci_dev *dev)
|
||||
{
|
||||
pci_disable_sriov(dev);
|
||||
|
||||
...
|
||||
}
|
||||
|
||||
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int dev_resume(struct pci_dev *dev)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void dev_shutdown(struct pci_dev *dev)
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
static struct pci_driver dev_driver = {
|
||||
.name = "SR-IOV Physical Function driver",
|
||||
.id_table = dev_id_table,
|
||||
.probe = dev_probe,
|
||||
.remove = __devexit_p(dev_remove),
|
||||
.suspend = dev_suspend,
|
||||
.resume = dev_resume,
|
||||
.shutdown = dev_shutdown,
|
||||
};
|
|
@ -25,7 +25,7 @@ use IO::Handle;
|
|||
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
|
||||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||
"opera1");
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" );
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
|
@ -37,8 +37,8 @@ for ($i=0; $i < scalar(@components); $i++) {
|
|||
$outfile = eval($cid);
|
||||
die $@ if $@;
|
||||
print STDERR <<EOF;
|
||||
Firmware $outfile extracted successfully.
|
||||
Now copy it to either /usr/lib/hotplug/firmware or /lib/firmware
|
||||
Firmware(s) $outfile extracted successfully.
|
||||
Now copy it(they) to either /usr/lib/hotplug/firmware or /lib/firmware
|
||||
(depending on configuration of firmware hotplug).
|
||||
EOF
|
||||
exit(0);
|
||||
|
@ -345,6 +345,85 @@ sub or51211 {
|
|||
$fwfile;
|
||||
}
|
||||
|
||||
sub cx231xx {
|
||||
my $fwfile = "v4l-cx231xx-avcore-01.fw";
|
||||
my $url = "http://linuxtv.org/downloads/firmware/$fwfile";
|
||||
my $hash = "7d3bb956dc9df0eafded2b56ba57cc42";
|
||||
|
||||
checkstandard();
|
||||
|
||||
wgetfile($fwfile, $url);
|
||||
verify($fwfile, $hash);
|
||||
|
||||
$fwfile;
|
||||
}
|
||||
|
||||
sub cx18 {
|
||||
my $url = "http://linuxtv.org/downloads/firmware/";
|
||||
|
||||
my %files = (
|
||||
'v4l-cx23418-apu.fw' => '588f081b562f5c653a3db1ad8f65939a',
|
||||
'v4l-cx23418-cpu.fw' => 'b6c7ed64bc44b1a6e0840adaeac39d79',
|
||||
'v4l-cx23418-dig.fw' => '95bc688d3e7599fd5800161e9971cc55',
|
||||
);
|
||||
|
||||
checkstandard();
|
||||
|
||||
my $allfiles;
|
||||
foreach my $fwfile (keys %files) {
|
||||
wgetfile($fwfile, "$url/$fwfile");
|
||||
verify($fwfile, $files{$fwfile});
|
||||
$allfiles .= " $fwfile";
|
||||
}
|
||||
|
||||
$allfiles =~ s/^\s//;
|
||||
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
sub cx23885 {
|
||||
my $url = "http://linuxtv.org/downloads/firmware/";
|
||||
|
||||
my %files = (
|
||||
'v4l-cx23885-avcore-01.fw' => 'a9f8f5d901a7fb42f552e1ee6384f3bb',
|
||||
'v4l-cx23885-enc.fw' => 'a9f8f5d901a7fb42f552e1ee6384f3bb',
|
||||
);
|
||||
|
||||
checkstandard();
|
||||
|
||||
my $allfiles;
|
||||
foreach my $fwfile (keys %files) {
|
||||
wgetfile($fwfile, "$url/$fwfile");
|
||||
verify($fwfile, $files{$fwfile});
|
||||
$allfiles .= " $fwfile";
|
||||
}
|
||||
|
||||
$allfiles =~ s/^\s//;
|
||||
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
sub pvrusb2 {
|
||||
my $url = "http://linuxtv.org/downloads/firmware/";
|
||||
|
||||
my %files = (
|
||||
'v4l-cx25840.fw' => 'dadb79e9904fc8af96e8111d9cb59320',
|
||||
);
|
||||
|
||||
checkstandard();
|
||||
|
||||
my $allfiles;
|
||||
foreach my $fwfile (keys %files) {
|
||||
wgetfile($fwfile, "$url/$fwfile");
|
||||
verify($fwfile, $files{$fwfile});
|
||||
$allfiles .= " $fwfile";
|
||||
}
|
||||
|
||||
$allfiles =~ s/^\s//;
|
||||
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
sub or51132_qam {
|
||||
my $fwfile = "dvb-fe-or51132-qam.fw";
|
||||
my $url = "http://linuxtv.org/downloads/firmware/$fwfile";
|
||||
|
|
|
@ -11,8 +11,6 @@ aty128fb.txt
|
|||
- info on the ATI Rage128 frame buffer driver.
|
||||
cirrusfb.txt
|
||||
- info on the driver for Cirrus Logic chipsets.
|
||||
cyblafb/
|
||||
- directory with documentation files related to the cyblafb driver.
|
||||
deferred_io.txt
|
||||
- an introduction to deferred IO.
|
||||
fbcon.txt
|
||||
|
|
|
@ -1,13 +0,0 @@
|
|||
Bugs
|
||||
====
|
||||
|
||||
I currently don't know of any bug. Please do send reports to:
|
||||
- linux-fbdev-devel@lists.sourceforge.net
|
||||
- Knut_Petersen@t-online.de.
|
||||
|
||||
|
||||
Untested features
|
||||
=================
|
||||
|
||||
All LCD stuff is untested. If it worked in tridentfb, it should work in
|
||||
cyblafb. Please test and report the results to Knut_Petersen@t-online.de.
|
|
@ -1,7 +0,0 @@
|
|||
Thanks to
|
||||
=========
|
||||
* Alan Hourihane, for writing the X trident driver
|
||||
* Jani Monoses, for writing the tridentfb driver
|
||||
* Antonino A. Daplas, for review of the first published
|
||||
version of cyblafb and some code
|
||||
* Jochen Hein, for testing and a helpfull bug report
|
|
@ -1,17 +0,0 @@
|
|||
Available Documentation
|
||||
=======================
|
||||
|
||||
Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22,
|
||||
2001, available from VIA:
|
||||
|
||||
http://www.viavpsd.com/product/6/15/DS8601A182.pdf
|
||||
|
||||
The datasheet is incomplete, some registers that need to be programmed are not
|
||||
explained at all and important bits are listed as "reserved". But you really
|
||||
need the datasheet to understand the code. "p. xxx" comments refer to page
|
||||
numbers of this document.
|
||||
|
||||
XFree/XOrg drivers are available and of good quality, looking at the code
|
||||
there is a good idea if the datasheet does not provide enough information
|
||||
or if the datasheet seems to be wrong.
|
||||
|
|
@ -1,154 +0,0 @@
|
|||
#
|
||||
# Sample fb.modes file
|
||||
#
|
||||
# Provides an incomplete list of working modes for
|
||||
# the cyberblade/i1 graphics core.
|
||||
#
|
||||
# The value 4294967256 is used instead of -40. Of course, -40 is not
|
||||
# a really reasonable value, but chip design does not always follow
|
||||
# logic. Believe me, it's ok, and it's the way the BIOS does it.
|
||||
#
|
||||
# fbset requires 4294967256 in fb.modes and -40 as an argument to
|
||||
# the -t parameter. That's also not too reasonable, and it might change
|
||||
# in the future or might even be differt for your current version.
|
||||
#
|
||||
|
||||
mode "640x480-50"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 47619 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-60"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 39682 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-70"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 34013 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-72"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 33068 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-75"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 31746 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-80"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 29761 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "640x480-85"
|
||||
geometry 640 480 2048 4096 8
|
||||
timings 28011 4294967256 24 17 0 216 3
|
||||
endmode
|
||||
|
||||
mode "800x600-50"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 30303 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-60"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 25252 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-70"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 21645 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-72"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 21043 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-75"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 20202 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-80"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 18939 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "800x600-85"
|
||||
geometry 800 600 2048 4096 8
|
||||
timings 17825 96 24 14 0 136 11
|
||||
endmode
|
||||
|
||||
mode "1024x768-50"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 19054 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-60"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 15880 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-70"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 13610 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-72"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 13232 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-75"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 12703 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-80"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 11910 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1024x768-85"
|
||||
geometry 1024 768 2048 4096 8
|
||||
timings 11209 144 24 29 0 120 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-50"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 11114 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-60"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 9262 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-70"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 7939 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-72"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 7719 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-75"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 7410 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-80"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 6946 232 16 39 0 160 3
|
||||
endmode
|
||||
|
||||
mode "1280x1024-85"
|
||||
geometry 1280 1024 2048 4096 8
|
||||
timings 6538 232 16 39 0 160 3
|
||||
endmode
|
|
@ -1,79 +0,0 @@
|
|||
Speed
|
||||
=====
|
||||
|
||||
CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data
|
||||
for mode 1280x1024-[8,16,32]@61 Hz.
|
||||
|
||||
Test 1: Cat a file with 2000 lines of 0 characters.
|
||||
Test 2: Cat a file with 2000 lines of 80 characters.
|
||||
Test 3: Cat a file with 2000 lines of 160 characters.
|
||||
|
||||
All values show system time use in seconds, kernel 2.6.12 was used for
|
||||
the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a
|
||||
patch that speeds up kernel bitblitting a lot ( > 20%).
|
||||
|
||||
+-----------+-----------------------------------------------------+
|
||||
| | not accelerated |
|
||||
| TRIDENTFB +-----------------+-----------------+-----------------+
|
||||
| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp |
|
||||
| | noypan | ypan | noypan | ypan | noypan | ypan |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Test 1 | 4.31 | 4.33 | 6.05 | 12.81 | ---- | ---- |
|
||||
| Test 2 | 67.94 | 5.44 | 123.16 | 14.79 | ---- | ---- |
|
||||
| Test 3 | 131.36 | 6.55 | 240.12 | 16.76 | ---- | ---- |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Comments | | | completely bro- |
|
||||
| | | | ken, monitor |
|
||||
| | | | switches off |
|
||||
+-----------+-----------------+-----------------+-----------------+
|
||||
|
||||
|
||||
+-----------+-----------------------------------------------------+
|
||||
| | accelerated |
|
||||
| TRIDENTFB +-----------------+-----------------+-----------------+
|
||||
| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp |
|
||||
| | noypan | ypan | noypan | ypan | noypan | ypan |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Test 1 | ---- | ---- | 20.62 | 1.22 | ---- | ---- |
|
||||
| Test 2 | ---- | ---- | 22.61 | 3.19 | ---- | ---- |
|
||||
| Test 3 | ---- | ---- | 24.59 | 5.16 | ---- | ---- |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Comments | broken, writing | broken, ok only | completely bro- |
|
||||
| | to wrong places | if bgcolor is | ken, monitor |
|
||||
| | on screen + bug | black, bug in | switches off |
|
||||
| | in fillrect() | fillrect() | |
|
||||
+-----------+-----------------+-----------------+-----------------+
|
||||
|
||||
|
||||
+-----------+-----------------------------------------------------+
|
||||
| | not accelerated |
|
||||
| VESAFB +-----------------+-----------------+-----------------+
|
||||
| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp |
|
||||
| | noypan | ypan | noypan | ypan | noypan | ypan |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Test 1 | 4.26 | 3.76 | 5.99 | 7.23 | ---- | ---- |
|
||||
| Test 2 | 65.65 | 4.89 | 120.88 | 9.08 | ---- | ---- |
|
||||
| Test 3 | 126.91 | 5.94 | 235.77 | 11.03 | ---- | ---- |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Comments | vga=0x307 | vga=0x31a | vga=0x31b not |
|
||||
| | fh=80kHz | fh=80kHz | supported by |
|
||||
| | fv=75kHz | fv=75kHz | video BIOS and |
|
||||
| | | | hardware |
|
||||
+-----------+-----------------+-----------------+-----------------+
|
||||
|
||||
|
||||
+-----------+-----------------------------------------------------+
|
||||
| | accelerated |
|
||||
| CYBLAFB +-----------------+-----------------+-----------------+
|
||||
| | 8 bpp | 16 bpp | 32 bpp |
|
||||
| | noypan | ypan | noypan | ypan | noypan | ypan |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Test 1 | 8.02 | 0.23 | 19.04 | 0.61 | 57.12 | 2.74 |
|
||||
| Test 2 | 8.38 | 0.55 | 19.39 | 0.92 | 57.54 | 3.13 |
|
||||
| Test 3 | 8.73 | 0.86 | 19.74 | 1.24 | 57.95 | 3.51 |
|
||||
+-----------+--------+--------+--------+--------+--------+--------+
|
||||
| Comments | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
+-----------+-----------------+-----------------+-----------------+
|
|
@ -1,31 +0,0 @@
|
|||
TODO / Missing features
|
||||
=======================
|
||||
|
||||
Verify LCD stuff "stretch" and "center" options are
|
||||
completely untested ... this code needs to be
|
||||
verified. As I don't have access to such
|
||||
hardware, please contact me if you are
|
||||
willing run some tests.
|
||||
|
||||
Interlaced video modes The reason that interleaved
|
||||
modes are disabled is that I do not know
|
||||
the meaning of the vertical interlace
|
||||
parameter. Also the datasheet mentions a
|
||||
bit d8 of a horizontal interlace parameter,
|
||||
but nowhere the lower 8 bits. Please help
|
||||
if you can.
|
||||
|
||||
low-res double scan modes Who needs it?
|
||||
|
||||
accelerated color blitting Who needs it? The console driver does use color
|
||||
blitting for nothing but drawing the penguine,
|
||||
everything else is done using color expanding
|
||||
blitting of 1bpp character bitmaps.
|
||||
|
||||
ioctls Who needs it?
|
||||
|
||||
TV-out Will be done later. Use "vga= " at boot time
|
||||
to set a suitable video mode.
|
||||
|
||||
??? Feel free to contact me if you have any
|
||||
feature requests
|
|
@ -1,217 +0,0 @@
|
|||
CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
|
||||
into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
|
||||
tested using a VIA EPIA 5000 board.
|
||||
|
||||
Cyblafb - compiled into the kernel or as a module?
|
||||
==================================================
|
||||
|
||||
You might compile cyblafb either as a module or compile it permanently into the
|
||||
kernel.
|
||||
|
||||
Unless you have a real reason to do so you should not compile both vesafb and
|
||||
cyblafb permanently into the kernel. It's possible and it helps during the
|
||||
developement cycle, but it's useless and will at least block some otherwise
|
||||
usefull memory for ordinary users.
|
||||
|
||||
Selecting Modes
|
||||
===============
|
||||
|
||||
Startup Mode
|
||||
============
|
||||
|
||||
First of all, you might use the "vga=???" boot parameter as it is
|
||||
documented in vesafb.txt and svga.txt. Cyblafb will detect the video
|
||||
mode selected and will use the geometry and timings found by
|
||||
inspecting the hardware registers.
|
||||
|
||||
video=cyblafb vga=0x317
|
||||
|
||||
Alternatively you might use a combination of the mode, ref and bpp
|
||||
parameters. If you compiled the driver into the kernel, add something
|
||||
like this to the kernel command line:
|
||||
|
||||
video=cyblafb:1280x1024,bpp=16,ref=50 ...
|
||||
|
||||
If you compiled the driver as a module, the same mode would be
|
||||
selected by the following command:
|
||||
|
||||
modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...
|
||||
|
||||
None of the modes possible to select as startup modes are affected by
|
||||
the problems described at the end of the next subsection.
|
||||
|
||||
For all startup modes cyblafb chooses a virtual x resolution of 2048,
|
||||
the only exception is mode 1280x1024 in combination with 32 bpp. This
|
||||
allows ywrap scrolling for all those modes if rotation is 0 or 2, and
|
||||
also fast scrolling if rotation is 1 or 3. The default virtual y reso-
|
||||
lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32,
|
||||
again with the only exception of 1280x1024 at 32 bpp.
|
||||
|
||||
Please do set your video memory size to 8 Mb in the Bios setup. Other
|
||||
values will work, but performace is decreased for a lot of modes.
|
||||
|
||||
Mode changes using fbset
|
||||
========================
|
||||
|
||||
You might use fbset to change the video mode, see "man fbset". Cyblafb
|
||||
generally does assume that you know what you are doing. But it does
|
||||
some checks, especially those that are needed to prevent you from
|
||||
damaging your hardware.
|
||||
|
||||
- only 8, 16, 24 and 32 bpp video modes are accepted
|
||||
- interlaced video modes are not accepted
|
||||
- double scan video modes are not accepted
|
||||
- if a flat panel is found, cyblafb does not allow you
|
||||
to program a resolution higher than the physical
|
||||
resolution of the flat panel monitor
|
||||
- cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
|
||||
and (currently) 24 bit modes use a doubled vclk internally,
|
||||
the dotclock limit as seen by fbset is 115 MHz for those
|
||||
modes and 230 MHz for 8 and 16 bpp modes.
|
||||
- cyblafb will allow you to select very high resolutions as
|
||||
long as the hardware can be programmed to these modes. The
|
||||
documented limit 1600x1200 is not enforced, but don't expect
|
||||
perfect signal quality.
|
||||
|
||||
Any request that violates the rules given above will be either changed
|
||||
to something the hardware supports or an error value will be returned.
|
||||
|
||||
If you program a virtual y resolution higher than the hardware limit,
|
||||
cyblafb will silently decrease that value to the highest possible
|
||||
value. The same is true for a virtual x resolution that is not
|
||||
supported by the hardware. Cyblafb tries to adapt vyres first because
|
||||
vxres decides if ywrap scrolling is possible or not.
|
||||
|
||||
Attempts to disable acceleration are ignored, I believe that this is
|
||||
safe.
|
||||
|
||||
Some video modes that should work do not work as expected. If you use
|
||||
the standard fb.modes, fbset 640x480-60 will program that mode, but
|
||||
you will see a vertical area, about two characters wide, with only
|
||||
much darker characters than the other characters on the screen.
|
||||
Cyblafb does allow that mode to be set, as it does not violate the
|
||||
official specifications. It would need a lot of code to reliably sort
|
||||
out all invalid modes, playing around with the margin values will
|
||||
give a valid mode quickly. And if cyblafb would detect such an invalid
|
||||
mode, should it silently alter the requested values or should it
|
||||
report an error? Both options have some pros and cons. As stated
|
||||
above, none of the startup modes are affected, and if you set
|
||||
verbosity to 1 or higher, cyblafb will print the fbset command that
|
||||
would be needed to program that mode using fbset.
|
||||
|
||||
|
||||
Other Parameters
|
||||
================
|
||||
|
||||
|
||||
crt don't autodetect, assume monitor connected to
|
||||
standard VGA connector
|
||||
|
||||
fp don't autodetect, assume flat panel display
|
||||
connected to flat panel monitor interface
|
||||
|
||||
nativex inform driver about native x resolution of
|
||||
flat panel monitor connected to special
|
||||
interface (should be autodetected)
|
||||
|
||||
stretch stretch image to adapt low resolution modes to
|
||||
higer resolutions of flat panel monitors
|
||||
connected to special interface
|
||||
|
||||
center center image to adapt low resolution modes to
|
||||
higer resolutions of flat panel monitors
|
||||
connected to special interface
|
||||
|
||||
memsize use if autodetected memsize is wrong ...
|
||||
should never be necessary
|
||||
|
||||
nopcirr disable PCI read retry
|
||||
nopciwr disable PCI write retry
|
||||
nopcirb disable PCI read bursts
|
||||
nopciwb disable PCI write bursts
|
||||
|
||||
bpp bpp for specified modes
|
||||
valid values: 8 || 16 || 24 || 32
|
||||
|
||||
ref refresh rate for specified mode
|
||||
valid values: 50 <= ref <= 85
|
||||
|
||||
mode 640x480 or 800x600 or 1024x768 or 1280x1024
|
||||
if not specified, the startup mode will be detected
|
||||
and used, so you might also use the vga=??? parameter
|
||||
described in vesafb.txt. If you do not specify a mode,
|
||||
bpp and ref parameters are ignored.
|
||||
|
||||
verbosity 0 is the default, increase to at least 2 for every
|
||||
bug report!
|
||||
|
||||
Development hints
|
||||
=================
|
||||
|
||||
It's much faster do compile a module and to load the new version after
|
||||
unloading the old module than to compile a new kernel and to reboot. So if you
|
||||
try to work on cyblafb, it might be a good idea to use cyblafb as a module.
|
||||
In real life, fast often means dangerous, and that's also the case here. If
|
||||
you introduce a serious bug when cyblafb is compiled into the kernel, the
|
||||
kernel will lock or oops with a high probability before the file system is
|
||||
mounted, and the danger for your data is low. If you load a broken own version
|
||||
of cyblafb on a running system, the danger for the integrity of the file
|
||||
system is much higher as you might need a hard reset afterwards. Decide
|
||||
yourself.
|
||||
|
||||
Module unloading, the vfb method
|
||||
================================
|
||||
|
||||
If you want to unload/reload cyblafb using the virtual framebuffer, you need
|
||||
to enable vfb support in the kernel first. After that, load the modules as
|
||||
shown below:
|
||||
|
||||
modprobe vfb vfb_enable=1
|
||||
modprobe fbcon
|
||||
modprobe cyblafb
|
||||
fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
|
||||
con2fb /dev/fb1 /dev/tty1
|
||||
...
|
||||
|
||||
If you now made some changes to cyblafb and want to reload it, you might do it
|
||||
as show below:
|
||||
|
||||
con2fb /dev/fb0 /dev/tty1
|
||||
...
|
||||
rmmod cyblafb
|
||||
modprobe cyblafb
|
||||
con2fb /dev/fb1 /dev/tty1
|
||||
...
|
||||
|
||||
Of course, you might choose another mode, and most certainly you also want to
|
||||
map some other /dev/tty* to the real framebuffer device. You might also choose
|
||||
to compile fbcon as a kernel module or place it permanently in the kernel.
|
||||
|
||||
I do not know of any way to unload fbcon, and fbcon will prevent the
|
||||
framebuffer device loaded first from unloading. [If there is a way, then
|
||||
please add a description here!]
|
||||
|
||||
Module unloading, the vesafb method
|
||||
===================================
|
||||
|
||||
Configure the kernel:
|
||||
|
||||
<*> Support for frame buffer devices
|
||||
[*] VESA VGA graphics support
|
||||
<M> Cyberblade/i1 support
|
||||
|
||||
Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
|
||||
parameter is important, choose any vga parameter you like as long as it is
|
||||
a graphics mode.
|
||||
|
||||
After booting, load cyblafb without any mode and bpp parameter and assign
|
||||
cyblafb to individual ttys using con2fb, e.g.:
|
||||
|
||||
modprobe cyblafb
|
||||
con2fb /dev/fb1 /dev/tty1
|
||||
|
||||
Unloading cyblafb works without problems after you assign vesafb to all
|
||||
ttys again, e.g.:
|
||||
|
||||
con2fb /dev/fb0 /dev/tty1
|
||||
rmmod cyblafb
|
|
@ -1,29 +0,0 @@
|
|||
0.62
|
||||
====
|
||||
|
||||
- the vesafb parameter has been removed as I decided to allow the
|
||||
feature without any special parameter.
|
||||
|
||||
- Cyblafb does not use the vga style of panning any longer, now the
|
||||
"right view" register in the graphics engine IO space is used. Without
|
||||
that change it was impossible to use all available memory, and without
|
||||
access to all available memory it is impossible to ywrap.
|
||||
|
||||
- The imageblit function now uses hardware acceleration for all font
|
||||
widths. Hardware blitting across pixel column 2048 is broken in the
|
||||
cyberblade/i1 graphics core, but we work around that hardware bug.
|
||||
|
||||
- modes with vxres != xres are supported now.
|
||||
|
||||
- ywrap scrolling is supported now and the default. This is a big
|
||||
performance gain.
|
||||
|
||||
- default video modes use vyres > yres and vxres > xres to allow
|
||||
almost optimal scrolling speed for normal and rotated screens
|
||||
|
||||
- some features mainly usefull for debugging the upper layers of the
|
||||
framebuffer system have been added, have a look at the code
|
||||
|
||||
- fixed: Oops after unloading cyblafb when reading /proc/io*
|
||||
|
||||
- we work around some bugs of the higher framebuffer layers.
|
|
@ -1,85 +0,0 @@
|
|||
I tried the following framebuffer drivers:
|
||||
|
||||
- TRIDENTFB is full of bugs. Acceleration is broken for Blade3D
|
||||
graphics cores like the cyberblade/i1. It claims to support a great
|
||||
number of devices, but documentation for most of these devices is
|
||||
unfortunately not available. There is _no_ reason to use tridentfb
|
||||
for cyberblade/i1 + CRT users. VESAFB is faster, and the one
|
||||
advantage, mode switching, is broken in tridentfb.
|
||||
|
||||
- VESAFB is used by many distributions as a standard. Vesafb does
|
||||
not support mode switching. VESAFB is a bit faster than the working
|
||||
configurations of TRIDENTFB, but it is still too slow, even if you
|
||||
use ypan.
|
||||
|
||||
- EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1
|
||||
graphics core, but it still has serious bugs and developement seems
|
||||
to have stopped. This is the one driver with TV-out support. If you
|
||||
do need this feature, try epiafb.
|
||||
|
||||
None of these drivers was a real option for me.
|
||||
|
||||
I believe that is unreasonable to change code that announces to support 20
|
||||
devices if I only have more or less sufficient documentation for exactly one
|
||||
of these. The risk of breaking device foo while fixing device bar is too high.
|
||||
|
||||
So I decided to start CyBlaFB as a stripped down tridentfb.
|
||||
|
||||
All code specific to other Trident chips has been removed. After that there
|
||||
were a lot of cosmetic changes to increase the readability of the code. All
|
||||
register names were changed to those mnemonics used in the datasheet. Function
|
||||
and macro names were changed if they hindered easy understanding of the code.
|
||||
|
||||
After that I debugged the code and implemented some new features. I'll try to
|
||||
give a little summary of the main changes:
|
||||
|
||||
- calculation of vertical and horizontal timings was fixed
|
||||
|
||||
- video signal quality has been improved dramatically
|
||||
|
||||
- acceleration:
|
||||
|
||||
- fillrect and copyarea were fixed and reenabled
|
||||
|
||||
- color expanding imageblit was newly implemented, color
|
||||
imageblit (only used to draw the penguine) still uses the
|
||||
generic code.
|
||||
|
||||
- init of the acceleration engine was improved and moved to a
|
||||
place where it really works ...
|
||||
|
||||
- sync function has a timeout now and tries to reset and
|
||||
reinit the accel engine if necessary
|
||||
|
||||
- fewer slow copyarea calls when doing ypan scrolling by using
|
||||
undocumented bit d21 of screen start address stored in
|
||||
CR2B[5]. BIOS does use it also, so this should be safe.
|
||||
|
||||
- cyblafb rejects any attempt to set modes that would cause vclk
|
||||
values above reasonable 230 MHz. 32bit modes use a clock
|
||||
multiplicator of 2, so fbset does show the correct values for
|
||||
pixclock but not for vclk in this case. The fbset limit is 115 MHz
|
||||
for 32 bpp modes.
|
||||
|
||||
- cyblafb rejects modes known to be broken or unimplemented (all
|
||||
interlaced modes, all doublescan modes for now)
|
||||
|
||||
- cyblafb now works independant of the video mode in effect at startup
|
||||
time (tridentfb does not init all needed registers to reasonable
|
||||
values)
|
||||
|
||||
- switching between video modes does work reliably now
|
||||
|
||||
- the first video mode now is the one selected on startup using the
|
||||
vga=???? mechanism or any of
|
||||
- 640x480, 800x600, 1024x768, 1280x1024
|
||||
- 8, 16, 24 or 32 bpp
|
||||
- refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32
|
||||
is limited to 63Hz)
|
||||
|
||||
- pci retry and pci burst mode are settable (try to disable if you
|
||||
experience latency problems)
|
||||
|
||||
- built as a module cyblafb might be unloaded and reloaded using
|
||||
the vfb module and con2vt or might be used together with vesafb
|
||||
|
|
@ -64,10 +64,10 @@ Who: Pavel Machek <pavel@suse.cz>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
||||
When: December 2008
|
||||
Files: include/linux/video_decoder.h include/linux/videodev.h
|
||||
Check: include/linux/video_decoder.h include/linux/videodev.h
|
||||
What: Video4Linux API 1 ioctls and from Video devices.
|
||||
When: July 2009
|
||||
Files: include/linux/videodev.h
|
||||
Check: include/linux/videodev.h
|
||||
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
|
||||
|
@ -311,6 +311,18 @@ Who: Vlad Yasevich <vladislav.yasevich@hp.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: Ability for non root users to shm_get hugetlb pages based on mlock
|
||||
resource limits
|
||||
When: 2.6.31
|
||||
Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
|
||||
have CAP_IPC_LOCK to be able to allocate shm segments backed by
|
||||
huge pages. The mlock based rlimit check to allow shm hugetlb is
|
||||
inconsistent with mmap based allocations. Hence it is being
|
||||
deprecated.
|
||||
Who: Ravikiran Thirumalai <kiran@scalex86.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_THERMAL_HWMON
|
||||
When: January 2009
|
||||
Why: This option was introduced just to allow older lm-sensors userspace
|
||||
|
@ -380,3 +392,35 @@ Why: The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t)
|
|||
have been kept around for migration reasons. After more than two years
|
||||
it's time to remove them finally
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: fakephp and associated sysfs files in /sys/bus/pci/slots/
|
||||
When: 2011
|
||||
Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
||||
represent a machine's physical PCI slots. The change in semantics
|
||||
had userspace implications, as the hotplug core no longer allowed
|
||||
drivers to create multiple sysfs files per physical slot (required
|
||||
for multi-function devices, e.g.). fakephp was seen as a developer's
|
||||
tool only, and its interface changed. Too late, we learned that
|
||||
there were some users of the fakephp interface.
|
||||
|
||||
In 2.6.30, the original fakephp interface was restored. At the same
|
||||
time, the PCI core gained the ability that fakephp provided, namely
|
||||
function-level hot-remove and hot-add.
|
||||
|
||||
Since the PCI core now provides the same functionality, exposed in:
|
||||
|
||||
/sys/bus/pci/rescan
|
||||
/sys/bus/pci/devices/.../remove
|
||||
/sys/bus/pci/devices/.../rescan
|
||||
|
||||
there is no functional reason to maintain fakephp as well.
|
||||
|
||||
We will keep the existing module so that 'modprobe fakephp' will
|
||||
present the old /sys/bus/pci/slots/... interface for compatibility,
|
||||
but users are urged to migrate their applications to the API above.
|
||||
|
||||
After a reasonable transition period, we will remove the legacy
|
||||
fakephp interface.
|
||||
Who: Alex Chiang <achiang@hp.com>
|
||||
|
|
|
@ -505,7 +505,7 @@ prototypes:
|
|||
void (*open)(struct vm_area_struct*);
|
||||
void (*close)(struct vm_area_struct*);
|
||||
int (*fault)(struct vm_area_struct*, struct vm_fault *);
|
||||
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
|
||||
int (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
||||
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
||||
|
||||
locking rules:
|
||||
|
|
|
@ -85,7 +85,7 @@ Note: More extensive information for getting started with ext4 can be
|
|||
* extent format more robust in face of on-disk corruption due to magics,
|
||||
* internal redundancy in tree
|
||||
* improved file allocation (multi-block alloc)
|
||||
* fix 32000 subdirectory limit
|
||||
* lift 32000 subdirectory limit imposed by i_links_count[1]
|
||||
* nsec timestamps for mtime, atime, ctime, create time
|
||||
* inode version field on disk (NFSv4, Lustre)
|
||||
* reduced e2fsck time via uninit_bg feature
|
||||
|
@ -100,6 +100,9 @@ Note: More extensive information for getting started with ext4 can be
|
|||
* efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force
|
||||
the ordering)
|
||||
|
||||
[1] Filesystems with a block size of 1k may see a limit imposed by the
|
||||
directory hash tree having a maximum depth of two.
|
||||
|
||||
2.2 Candidate features for future inclusion
|
||||
|
||||
* Online defrag (patches available but not well tested)
|
||||
|
@ -180,8 +183,8 @@ commit=nrsec (*) Ext4 can be told to sync all its data and metadata
|
|||
performance.
|
||||
|
||||
barrier=<0|1(*)> This enables/disables the use of write barriers in
|
||||
the jbd code. barrier=0 disables, barrier=1 enables.
|
||||
This also requires an IO stack which can support
|
||||
barrier(*) the jbd code. barrier=0 disables, barrier=1 enables.
|
||||
nobarrier This also requires an IO stack which can support
|
||||
barriers, and if jbd gets an error on a barrier
|
||||
write, it will disable again with a warning.
|
||||
Write barriers enforce proper on-disk ordering
|
||||
|
@ -189,6 +192,9 @@ barrier=<0|1(*)> This enables/disables the use of write barriers in
|
|||
safe to use, at some performance penalty. If
|
||||
your disks are battery-backed in one way or another,
|
||||
disabling barriers may safely improve performance.
|
||||
The mount options "barrier" and "nobarrier" can
|
||||
also be used to enable or disable barriers, for
|
||||
consistency with other ext4 mount options.
|
||||
|
||||
inode_readahead=n This tuning parameter controls the maximum
|
||||
number of inode table blocks that ext4's inode
|
||||
|
@ -310,6 +316,24 @@ journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the
|
|||
a slightly higher priority than the default I/O
|
||||
priority.
|
||||
|
||||
auto_da_alloc(*) Many broken applications don't use fsync() when
|
||||
noauto_da_alloc replacing existing files via patterns such as
|
||||
fd = open("foo.new")/write(fd,..)/close(fd)/
|
||||
rename("foo.new", "foo"), or worse yet,
|
||||
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
|
||||
If auto_da_alloc is enabled, ext4 will detect
|
||||
the replace-via-rename and replace-via-truncate
|
||||
patterns and force that any delayed allocation
|
||||
blocks are allocated such that at the next
|
||||
journal commit, in the default data=ordered
|
||||
mode, the data blocks of the new file are forced
|
||||
to disk before the rename() operation is
|
||||
commited. This provides roughly the same level
|
||||
of guarantees as ext3, and avoids the
|
||||
"zero-length" problem that can happen when a
|
||||
system crashes before the delayed allocation
|
||||
blocks are forced to disk.
|
||||
|
||||
Data Mode
|
||||
=========
|
||||
There are 3 different data modes:
|
||||
|
|
|
@ -940,27 +940,6 @@ Table 1-10: Files in /proc/fs/ext4/<devname>
|
|||
File Content
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
mb_history multiblock allocation history
|
||||
stats controls whether the multiblock allocator should start
|
||||
collecting statistics, which are shown during the unmount
|
||||
group_prealloc the multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if the
|
||||
stripe size is not set in the ext4 superblock
|
||||
max_to_scan The maximum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
min_to_scan The minimum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
order2_req Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
stream_req Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out of a
|
||||
block group specific preallocation pool, so that small
|
||||
files are packed closely together. Each large file
|
||||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
inode_readahead Tuning parameter which controls the maximum number of
|
||||
inode table blocks that ext4's inode table readahead
|
||||
algorithm will pre-read into the buffer cache
|
||||
..............................................................................
|
||||
|
||||
|
||||
|
|
|
@ -12,6 +12,7 @@ that support it. For example, a given bus might look like this:
|
|||
| |-- enable
|
||||
| |-- irq
|
||||
| |-- local_cpus
|
||||
| |-- remove
|
||||
| |-- resource
|
||||
| |-- resource0
|
||||
| |-- resource1
|
||||
|
@ -36,6 +37,7 @@ files, each with their own function.
|
|||
enable Whether the device is enabled (ascii, rw)
|
||||
irq IRQ number (ascii, ro)
|
||||
local_cpus nearby CPU mask (cpumask, ro)
|
||||
remove remove device from kernel's list (ascii, wo)
|
||||
resource PCI resource host addresses (ascii, ro)
|
||||
resource0..N PCI resource N, if present (binary, mmap)
|
||||
resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
|
||||
|
@ -46,6 +48,7 @@ files, each with their own function.
|
|||
|
||||
ro - read only file
|
||||
rw - file is readable and writable
|
||||
wo - write only file
|
||||
mmap - file is mmapable
|
||||
ascii - file contains ascii text
|
||||
binary - file contains binary data
|
||||
|
@ -73,6 +76,13 @@ that the device must be enabled for a rom read to return data succesfully.
|
|||
In the event a driver is not bound to the device, it can be enabled using the
|
||||
'enable' file, documented above.
|
||||
|
||||
The 'remove' file is used to remove the PCI device, by writing a non-zero
|
||||
integer to the file. This does not involve any kind of hot-plug functionality,
|
||||
e.g. powering off the device. The device is removed from the kernel's list of
|
||||
PCI devices, the sysfs directory for it is removed, and the device will be
|
||||
removed from any drivers attached to it. Removal of PCI root buses is
|
||||
disallowed.
|
||||
|
||||
Accessing legacy resources through sysfs
|
||||
----------------------------------------
|
||||
|
||||
|
|
|
@ -49,12 +49,9 @@ of up to +/- 0.5 degrees even when compared against precise temperature
|
|||
readings. Be sure to have a high vs. low temperature limit gap of al least
|
||||
1.0 degree Celsius to avoid Tout "bouncing", though!
|
||||
|
||||
As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
|
||||
/sys file interface. The result consists mainly of bit 6 and 5 of the
|
||||
configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
|
||||
bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
|
||||
low limits are met or exceeded and are reset by the module as soon as the
|
||||
respective temperature ranges are left.
|
||||
The alarm bits are set when the high or low limits are met or exceeded and
|
||||
are reset by the module as soon as the respective temperature ranges are
|
||||
left.
|
||||
|
||||
The alarm registers are in no way suitable to find out about the actual
|
||||
status of Tout. They will only tell you about its history, whether or not
|
||||
|
@ -64,45 +61,3 @@ with neither of the alarms set.
|
|||
|
||||
Temperature conversion of the DS1621 takes up to 1000ms; internal access to
|
||||
non-volatile registers may last for 10ms or below.
|
||||
|
||||
High Accuracy Temperature Reading
|
||||
---------------------------------
|
||||
|
||||
As said before, the temperature issued via the 9-bit i2c-bus data is
|
||||
somewhat arbitrary. Internally, the temperature conversion is of a
|
||||
different kind that is explained (not so...) well in the DS1621 data sheet.
|
||||
To cut the long story short: Inside the DS1621 there are two oscillators,
|
||||
both of them biassed by a temperature coefficient.
|
||||
|
||||
Higher resolution of the temperature reading can be achieved using the
|
||||
internal projection, which means taking account of REG_COUNT and REG_SLOPE
|
||||
(the driver manages them):
|
||||
|
||||
Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
|
||||
Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
|
||||
Measurement with Dallas Direct-to-Digital Temperature Sensors'
|
||||
|
||||
- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
|
||||
- The resulting value is TEMP_READ.
|
||||
- Then, read REG_COUNT.
|
||||
- And then, REG_SLOPE.
|
||||
|
||||
TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
|
||||
|
||||
Note that this is what the DONE bit in the DS1621 configuration register is
|
||||
good for: Internally, one temperature conversion takes up to 1000ms. Before
|
||||
that conversion is complete you will not be able to read valid things out
|
||||
of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
|
||||
tells you whether the conversion is complete ("done", in plain English) and
|
||||
thus, whether the values you read are good or not.
|
||||
|
||||
The DS1621 has two modes of operation: "Continuous" conversion, which can
|
||||
be understood as the default stand-alone mode where the chip gets the
|
||||
temperature and controls external devices via its Tout pin or tells other
|
||||
i2c's about it if they care. The other mode is called "1SHOT", that means
|
||||
that it only figures out about the temperature when it is explicitly told
|
||||
to do so; this can be seen as power saving mode.
|
||||
|
||||
Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
|
||||
the continuous conversions until the contents of these registers are valid,
|
||||
or, in 1SHOT mode, you have to have one conversion made.
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
Kernel driver lis3lv02d
|
||||
==================
|
||||
=======================
|
||||
|
||||
Supported chips:
|
||||
|
||||
* STMicroelectronics LIS3LV02DL and LIS3LV02DQ
|
||||
|
||||
Author:
|
||||
Authors:
|
||||
Yan Burman <burman.yan@gmail.com>
|
||||
Eric Piel <eric.piel@tremplin-utc.net>
|
||||
|
||||
|
@ -15,7 +15,7 @@ Description
|
|||
|
||||
This driver provides support for the accelerometer found in various HP
|
||||
laptops sporting the feature officially called "HP Mobile Data
|
||||
Protection System 3D" or "HP 3D DriveGuard". It detect automatically
|
||||
Protection System 3D" or "HP 3D DriveGuard". It detects automatically
|
||||
laptops with this sensor. Known models (for now the HP 2133, nc6420,
|
||||
nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis
|
||||
automatically oriented on standard way (eg: you can directly play
|
||||
|
@ -27,7 +27,7 @@ position - 3D position that the accelerometer reports. Format: "(x,y,z)"
|
|||
calibrate - read: values (x, y, z) that are used as the base for input
|
||||
class device operation.
|
||||
write: forces the base to be recalibrated with the current
|
||||
position.
|
||||
position.
|
||||
rate - reports the sampling rate of the accelerometer device in HZ
|
||||
|
||||
This driver also provides an absolute input class device, allowing
|
||||
|
@ -48,7 +48,7 @@ For better compatibility between the various laptops. The values reported by
|
|||
the accelerometer are converted into a "standard" organisation of the axes
|
||||
(aka "can play neverball out of the box"):
|
||||
* When the laptop is horizontal the position reported is about 0 for X and Y
|
||||
and a positive value for Z
|
||||
and a positive value for Z
|
||||
* If the left side is elevated, X increases (becomes positive)
|
||||
* If the front side (where the touchpad is) is elevated, Y decreases
|
||||
(becomes negative)
|
||||
|
@ -59,3 +59,13 @@ email to the authors to add it to the database. When reporting a new
|
|||
laptop, please include the output of "dmidecode" plus the value of
|
||||
/sys/devices/platform/lis3lv02d/position in these four cases.
|
||||
|
||||
Q&A
|
||||
---
|
||||
|
||||
Q: How do I safely simulate freefall? I have an HP "portable
|
||||
workstation" which has about 3.5kg and a plastic case, so letting it
|
||||
fall to the ground is out of question...
|
||||
|
||||
A: The sensor is pretty sensitive, so your hands can do it. Lift it
|
||||
into free space, follow the fall with your hands for like 10
|
||||
centimeters. That should be enough to trigger the detection.
|
||||
|
|
50
Documentation/hwmon/ltc4215
Normal file
50
Documentation/hwmon/ltc4215
Normal file
|
@ -0,0 +1,50 @@
|
|||
Kernel driver ltc4215
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Linear Technology LTC4215
|
||||
Prefix: 'ltc4215'
|
||||
Addresses scanned: 0x44
|
||||
Datasheet:
|
||||
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1163,P17572,D12697
|
||||
|
||||
Author: Ira W. Snyder <iws@ovro.caltech.edu>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The LTC4215 controller allows a board to be safely inserted and removed
|
||||
from a live backplane.
|
||||
|
||||
|
||||
Usage Notes
|
||||
-----------
|
||||
|
||||
This driver does not probe for LTC4215 devices, due to the fact that some
|
||||
of the possible addresses are unfriendly to probing. You will need to use
|
||||
the "force" parameter to tell the driver where to find the device.
|
||||
|
||||
Example: the following will load the driver for an LTC4215 at address 0x44
|
||||
on I2C bus #0:
|
||||
$ modprobe ltc4215 force=0,0x44
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The LTC4215 has built-in limits for overvoltage, undervoltage, and
|
||||
undercurrent warnings. This makes it very likely that the reference
|
||||
circuit will be used.
|
||||
|
||||
in1_input input voltage
|
||||
in2_input output voltage
|
||||
|
||||
in1_min_alarm input undervoltage alarm
|
||||
in1_max_alarm input overvoltage alarm
|
||||
|
||||
curr1_input current
|
||||
curr1_max_alarm overcurrent alarm
|
||||
|
||||
power1_input power usage
|
||||
power1_alarm power bad alarm
|
|
@ -365,6 +365,7 @@ energy[1-*]_input Cumulative energy use
|
|||
Unit: microJoule
|
||||
RO
|
||||
|
||||
|
||||
**********
|
||||
* Alarms *
|
||||
**********
|
||||
|
@ -453,6 +454,27 @@ beep_mask Bitmask for beep.
|
|||
RW
|
||||
|
||||
|
||||
***********************
|
||||
* Intrusion detection *
|
||||
***********************
|
||||
|
||||
intrusion[0-*]_alarm
|
||||
Chassis intrusion detection
|
||||
0: OK
|
||||
1: intrusion detected
|
||||
RW
|
||||
Contrary to regular alarm flags which clear themselves
|
||||
automatically when read, this one sticks until cleared by
|
||||
the user. This is done by writing 0 to the file. Writing
|
||||
other values is unsupported.
|
||||
|
||||
intrusion[0-*]_beep
|
||||
Chassis intrusion beep
|
||||
0: disable
|
||||
1: enable
|
||||
RW
|
||||
|
||||
|
||||
sysfs attribute writes interpretation
|
||||
-------------------------------------
|
||||
|
||||
|
|
|
@ -2,30 +2,40 @@ Kernel driver w83627ehf
|
|||
=======================
|
||||
|
||||
Supported chips:
|
||||
* Winbond W83627EHF/EHG/DHG (ISA access ONLY)
|
||||
* Winbond W83627EHF/EHG (ISA access ONLY)
|
||||
Prefix: 'w83627ehf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet:
|
||||
http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
|
||||
DHG datasheet confidential.
|
||||
http://www.nuvoton.com.tw/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf
|
||||
* Winbond W83627DHG
|
||||
Prefix: 'w83627dhg'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet:
|
||||
http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf
|
||||
* Winbond W83667HG
|
||||
Prefix: 'w83667hg'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: not available
|
||||
|
||||
Authors:
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
Yuan Mu (Winbond)
|
||||
Rudolf Marek <r.marek@assembler.cz>
|
||||
David Hubbard <david.c.hubbard@gmail.com>
|
||||
Gong Jun <JGong@nuvoton.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Winbond W83627EHF, W83627EHG, and
|
||||
W83627DHG super I/O chips. We will refer to them collectively as Winbond chips.
|
||||
This driver implements support for the Winbond W83627EHF, W83627EHG,
|
||||
W83627DHG and W83667HG super I/O chips. We will refer to them collectively
|
||||
as Winbond chips.
|
||||
|
||||
The chips implement three temperature sensors, five fan rotation
|
||||
speed sensors, ten analog voltage sensors (only nine for the 627DHG), one
|
||||
VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG), alarms with beep
|
||||
warnings (control unimplemented), and some automatic fan regulation
|
||||
strategies (plus manual fan control mode).
|
||||
VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG and 667HG), alarms
|
||||
with beep warnings (control unimplemented), and some automatic fan
|
||||
regulation strategies (plus manual fan control mode).
|
||||
|
||||
Temperatures are measured in degrees Celsius and measurement resolution is 1
|
||||
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
|
||||
|
@ -54,7 +64,8 @@ follows:
|
|||
temp1 -> pwm1
|
||||
temp2 -> pwm2
|
||||
temp3 -> pwm3
|
||||
prog -> pwm4 (the programmable setting is not supported by the driver)
|
||||
prog -> pwm4 (not on 667HG; the programmable setting is not supported by
|
||||
the driver)
|
||||
|
||||
/sys files
|
||||
----------
|
||||
|
|
|
@ -122,10 +122,8 @@ Code Seq# Include File Comments
|
|||
'c' 00-7F linux/coda.h conflict!
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h
|
||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||
'd' 00-DF linux/video_decoder.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
'e' all linux/digi1.h conflict!
|
||||
'e' 00-1F linux/video_encoder.h conflict!
|
||||
'e' 00-1F net/irda/irtty.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h
|
||||
'h' 00-7F Charon filesystem
|
||||
|
|
|
@ -492,6 +492,16 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Range: 0 - 8192
|
||||
Default: 64
|
||||
|
||||
dma_debug=off If the kernel is compiled with DMA_API_DEBUG support
|
||||
this option disables the debugging code at boot.
|
||||
|
||||
dma_debug_entries=<number>
|
||||
This option allows to tune the number of preallocated
|
||||
entries for DMA-API debugging code. One entry is
|
||||
required per DMA-API allocation. Use this if the
|
||||
DMA-API debugging code disables itself because the
|
||||
architectural default is too low.
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force |
|
||||
verbose }
|
||||
|
@ -1687,6 +1697,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See also Documentation/blockdev/paride.txt.
|
||||
|
||||
pci=option[,option...] [PCI] various PCI subsystem options:
|
||||
earlydump [X86] dump PCI config space before the kernel
|
||||
changes anything
|
||||
off [X86] don't probe for the PCI bus
|
||||
bios [X86-32] force use of PCI BIOS, don't access
|
||||
the hardware directly. Use this if your machine
|
||||
|
@ -1786,6 +1798,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
cbmemsize=nn[KMG] The fixed amount of bus space which is
|
||||
reserved for the CardBus bridge's memory
|
||||
window. The default value is 64 megabytes.
|
||||
resource_alignment=
|
||||
Format:
|
||||
[<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
|
||||
Specifies alignment and device to reassign
|
||||
aligned memory resources.
|
||||
If <order of align> is not specified,
|
||||
PAGE_SIZE is used as alignment.
|
||||
PCI-PCI bridge can be specified, if resource
|
||||
windows need to be expanded.
|
||||
|
||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||
Management.
|
||||
|
|
|
@ -1630,6 +1630,13 @@ static bool service_io(struct device *dev)
|
|||
}
|
||||
}
|
||||
|
||||
/* OK, so we noted that it was pretty poor to use an fdatasync as a
|
||||
* barrier. But Christoph Hellwig points out that we need a sync
|
||||
* *afterwards* as well: "Barriers specify no reordering to the front
|
||||
* or the back." And Jens Axboe confirmed it, so here we are: */
|
||||
if (out->type & VIRTIO_BLK_T_BARRIER)
|
||||
fdatasync(vblk->fd);
|
||||
|
||||
/* We can't trigger an IRQ, because we're not the Launcher. It does
|
||||
* that when we tell it we're done. */
|
||||
add_used(dev->vq, head, wlen);
|
||||
|
|
|
@ -27,33 +27,37 @@ lock-class.
|
|||
State
|
||||
-----
|
||||
|
||||
The validator tracks lock-class usage history into 5 separate state bits:
|
||||
The validator tracks lock-class usage history into 4n + 1 separate state bits:
|
||||
|
||||
- 'ever held in hardirq context' [ == hardirq-safe ]
|
||||
- 'ever held in softirq context' [ == softirq-safe ]
|
||||
- 'ever held with hardirqs enabled' [ == hardirq-unsafe ]
|
||||
- 'ever held with softirqs and hardirqs enabled' [ == softirq-unsafe ]
|
||||
- 'ever held in STATE context'
|
||||
- 'ever head as readlock in STATE context'
|
||||
- 'ever head with STATE enabled'
|
||||
- 'ever head as readlock with STATE enabled'
|
||||
|
||||
Where STATE can be either one of (kernel/lockdep_states.h)
|
||||
- hardirq
|
||||
- softirq
|
||||
- reclaim_fs
|
||||
|
||||
- 'ever used' [ == !unused ]
|
||||
|
||||
When locking rules are violated, these 4 state bits are presented in the
|
||||
locking error messages, inside curlies. A contrived example:
|
||||
When locking rules are violated, these state bits are presented in the
|
||||
locking error messages, inside curlies. A contrived example:
|
||||
|
||||
modprobe/2287 is trying to acquire lock:
|
||||
(&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24
|
||||
(&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
|
||||
|
||||
but task is already holding lock:
|
||||
(&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24
|
||||
(&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
|
||||
|
||||
|
||||
The bit position indicates hardirq, softirq, hardirq-read,
|
||||
softirq-read respectively, and the character displayed in each
|
||||
indicates:
|
||||
The bit position indicates STATE, STATE-read, for each of the states listed
|
||||
above, and the character displayed in each indicates:
|
||||
|
||||
'.' acquired while irqs disabled
|
||||
'+' acquired in irq context
|
||||
'-' acquired with irqs enabled
|
||||
'?' read acquired in irq context with irqs enabled.
|
||||
'?' acquired in irq context with irqs enabled.
|
||||
|
||||
Unused mutexes cannot be part of the cause of an error.
|
||||
|
||||
|
|
62
Documentation/misc-devices/isl29003
Normal file
62
Documentation/misc-devices/isl29003
Normal file
|
@ -0,0 +1,62 @@
|
|||
Kernel driver isl29003
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Intersil ISL29003
|
||||
Prefix: 'isl29003'
|
||||
Addresses scanned: none
|
||||
Datasheet:
|
||||
http://www.intersil.com/data/fn/fn7464.pdf
|
||||
|
||||
Author: Daniel Mack <daniel@caiaq.de>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
The ISL29003 is an integrated light sensor with a 16-bit integrating type
|
||||
ADC, I2C user programmable lux range select for optimized counts/lux, and
|
||||
I2C multi-function control and monitoring capabilities. The internal ADC
|
||||
provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by
|
||||
artificial light sources.
|
||||
|
||||
The driver allows to set the lux range, the bit resolution, the operational
|
||||
mode (see below) and the power state of device and can read the current lux
|
||||
value, of course.
|
||||
|
||||
|
||||
Detection
|
||||
---------
|
||||
|
||||
The ISL29003 does not have an ID register which could be used to identify
|
||||
it, so the detection routine will just try to read from the configured I2C
|
||||
addess and consider the device to be present as soon as it ACKs the
|
||||
transfer.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
range:
|
||||
0: 0 lux to 1000 lux (default)
|
||||
1: 0 lux to 4000 lux
|
||||
2: 0 lux to 16,000 lux
|
||||
3: 0 lux to 64,000 lux
|
||||
|
||||
resolution:
|
||||
0: 2^16 cycles (default)
|
||||
1: 2^12 cycles
|
||||
2: 2^8 cycles
|
||||
3: 2^4 cycles
|
||||
|
||||
mode:
|
||||
0: diode1's current (unsigned 16bit) (default)
|
||||
1: diode1's current (unsigned 16bit)
|
||||
2: difference between diodes (l1 - l2, signed 15bit)
|
||||
|
||||
power_state:
|
||||
0: device is disabled (default)
|
||||
1: device is enabled
|
||||
|
||||
lux (read only):
|
||||
returns the value from the last sensor reading
|
||||
|
|
@ -35,30 +35,30 @@ Example:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
|
||||
reg = <82a8 4>;
|
||||
ranges = <0 8100 1a4>;
|
||||
reg = <0x82a8 4>;
|
||||
ranges = <0 0x8100 0x1a4>;
|
||||
interrupt-parent = <&ipic>;
|
||||
interrupts = <47 8>;
|
||||
interrupts = <71 8>;
|
||||
cell-index = <0>;
|
||||
dma-channel@0 {
|
||||
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
|
||||
cell-index = <0>;
|
||||
reg = <0 80>;
|
||||
reg = <0 0x80>;
|
||||
};
|
||||
dma-channel@80 {
|
||||
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
|
||||
cell-index = <1>;
|
||||
reg = <80 80>;
|
||||
reg = <0x80 0x80>;
|
||||
};
|
||||
dma-channel@100 {
|
||||
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
|
||||
cell-index = <2>;
|
||||
reg = <100 80>;
|
||||
reg = <0x100 0x80>;
|
||||
};
|
||||
dma-channel@180 {
|
||||
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
|
||||
cell-index = <3>;
|
||||
reg = <180 80>;
|
||||
reg = <0x180 0x80>;
|
||||
};
|
||||
};
|
||||
|
||||
|
@ -93,36 +93,36 @@ Example:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
|
||||
reg = <21300 4>;
|
||||
ranges = <0 21100 200>;
|
||||
reg = <0x21300 4>;
|
||||
ranges = <0 0x21100 0x200>;
|
||||
cell-index = <0>;
|
||||
dma-channel@0 {
|
||||
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
|
||||
reg = <0 80>;
|
||||
reg = <0 0x80>;
|
||||
cell-index = <0>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <14 2>;
|
||||
interrupts = <20 2>;
|
||||
};
|
||||
dma-channel@80 {
|
||||
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
|
||||
reg = <80 80>;
|
||||
reg = <0x80 0x80>;
|
||||
cell-index = <1>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <15 2>;
|
||||
interrupts = <21 2>;
|
||||
};
|
||||
dma-channel@100 {
|
||||
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
|
||||
reg = <100 80>;
|
||||
reg = <0x100 0x80>;
|
||||
cell-index = <2>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <16 2>;
|
||||
interrupts = <22 2>;
|
||||
};
|
||||
dma-channel@180 {
|
||||
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
|
||||
reg = <180 80>;
|
||||
reg = <0x180 0x80>;
|
||||
cell-index = <3>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <17 2>;
|
||||
interrupts = <23 2>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
24
Documentation/powerpc/dts-bindings/fsl/esdhc.txt
Normal file
24
Documentation/powerpc/dts-bindings/fsl/esdhc.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
* Freescale Enhanced Secure Digital Host Controller (eSDHC)
|
||||
|
||||
The Enhanced Secure Digital Host Controller provides an interface
|
||||
for MMC, SD, and SDIO types of memory cards.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be
|
||||
"fsl,<chip>-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors.
|
||||
"fsl,<chip>-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors.
|
||||
- reg : should contain eSDHC registers location and length.
|
||||
- interrupts : should contain eSDHC interrupt.
|
||||
- interrupt-parent : interrupt source phandle.
|
||||
- clock-frequency : specifies eSDHC base clock frequency.
|
||||
|
||||
Example:
|
||||
|
||||
sdhci@2e000 {
|
||||
compatible = "fsl,mpc8378-esdhc", "fsl,mpc8379-esdhc";
|
||||
reg = <0x2e000 0x1000>;
|
||||
interrupts = <42 0x8>;
|
||||
interrupt-parent = <&ipic>;
|
||||
/* Filled in by U-Boot */
|
||||
clock-frequency = <0>;
|
||||
};
|
|
@ -4,44 +4,56 @@ The SSI is a serial device that communicates with audio codecs. It can
|
|||
be programmed in AC97, I2S, left-justified, or right-justified modes.
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, containing "fsl,ssi"
|
||||
- cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
|
||||
- reg : offset and length of the register set for the device
|
||||
- interrupts : <a b> where a is the interrupt number and b is a
|
||||
field that represents an encoding of the sense and
|
||||
level information for the interrupt. This should be
|
||||
encoded based on the information in section 2)
|
||||
depending on the type of interrupt controller you
|
||||
have.
|
||||
- interrupt-parent : the phandle for the interrupt controller that
|
||||
services interrupts for this device.
|
||||
- fsl,mode : the operating mode for the SSI interface
|
||||
"i2s-slave" - I2S mode, SSI is clock slave
|
||||
"i2s-master" - I2S mode, SSI is clock master
|
||||
"lj-slave" - left-justified mode, SSI is clock slave
|
||||
"lj-master" - l.j. mode, SSI is clock master
|
||||
"rj-slave" - right-justified mode, SSI is clock slave
|
||||
"rj-master" - r.j., SSI is clock master
|
||||
"ac97-slave" - AC97 mode, SSI is clock slave
|
||||
"ac97-master" - AC97 mode, SSI is clock master
|
||||
- fsl,playback-dma: phandle to a node for the DMA channel to use for
|
||||
- compatible: Compatible list, contains "fsl,ssi".
|
||||
- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on.
|
||||
- reg: Offset and length of the register set for the device.
|
||||
- interrupts: <a b> where a is the interrupt number and b is a
|
||||
field that represents an encoding of the sense and
|
||||
level information for the interrupt. This should be
|
||||
encoded based on the information in section 2)
|
||||
depending on the type of interrupt controller you
|
||||
have.
|
||||
- interrupt-parent: The phandle for the interrupt controller that
|
||||
services interrupts for this device.
|
||||
- fsl,mode: The operating mode for the SSI interface.
|
||||
"i2s-slave" - I2S mode, SSI is clock slave
|
||||
"i2s-master" - I2S mode, SSI is clock master
|
||||
"lj-slave" - left-justified mode, SSI is clock slave
|
||||
"lj-master" - l.j. mode, SSI is clock master
|
||||
"rj-slave" - right-justified mode, SSI is clock slave
|
||||
"rj-master" - r.j., SSI is clock master
|
||||
"ac97-slave" - AC97 mode, SSI is clock slave
|
||||
"ac97-master" - AC97 mode, SSI is clock master
|
||||
- fsl,playback-dma: Phandle to a node for the DMA channel to use for
|
||||
playback of audio. This is typically dictated by SOC
|
||||
design. See the notes below.
|
||||
- fsl,capture-dma: phandle to a node for the DMA channel to use for
|
||||
- fsl,capture-dma: Phandle to a node for the DMA channel to use for
|
||||
capture (recording) of audio. This is typically dictated
|
||||
by SOC design. See the notes below.
|
||||
- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs.
|
||||
This number is the maximum allowed value for SFCSR[TFWM0].
|
||||
- fsl,ssi-asynchronous:
|
||||
If specified, the SSI is to be programmed in asynchronous
|
||||
mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
|
||||
all be connected to valid signals. In synchronous mode,
|
||||
SRCK and SRFS are ignored. Asynchronous mode allows
|
||||
playback and capture to use different sample sizes and
|
||||
sample rates. Some drivers may require that SRCK and STCK
|
||||
be connected together, and SRFS and STFS be connected
|
||||
together. This would still allow different sample sizes,
|
||||
but not different sample rates.
|
||||
|
||||
Optional properties:
|
||||
- codec-handle : phandle to a 'codec' node that defines an audio
|
||||
codec connected to this SSI. This node is typically
|
||||
a child of an I2C or other control node.
|
||||
- codec-handle: Phandle to a 'codec' node that defines an audio
|
||||
codec connected to this SSI. This node is typically
|
||||
a child of an I2C or other control node.
|
||||
|
||||
Child 'codec' node required properties:
|
||||
- compatible : compatible list, contains the name of the codec
|
||||
- compatible: Compatible list, contains the name of the codec
|
||||
|
||||
Child 'codec' node optional properties:
|
||||
- clock-frequency : The frequency of the input clock, which typically
|
||||
comes from an on-board dedicated oscillator.
|
||||
- clock-frequency: The frequency of the input clock, which typically comes
|
||||
from an on-board dedicated oscillator.
|
||||
|
||||
Notes on fsl,playback-dma and fsl,capture-dma:
|
||||
|
||||
|
|
23
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
Normal file
23
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
Normal file
|
@ -0,0 +1,23 @@
|
|||
MMC/SD/SDIO slot directly connected to a SPI bus
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "mmc-spi-slot".
|
||||
- reg : should specify SPI address (chip-select number).
|
||||
- spi-max-frequency : maximum frequency for this device (Hz).
|
||||
- voltage-ranges : two cells are required, first cell specifies minimum
|
||||
slot voltage (mV), second cell specifies maximum slot voltage (mV).
|
||||
Several ranges could be specified.
|
||||
- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO,
|
||||
Write-Protect GPIO.
|
||||
|
||||
Example:
|
||||
|
||||
mmc-slot@0 {
|
||||
compatible = "fsl,mpc8323rdb-mmc-slot",
|
||||
"mmc-spi-slot";
|
||||
reg = <0>;
|
||||
gpios = <&qe_pio_d 14 1
|
||||
&qe_pio_d 15 0>;
|
||||
voltage-ranges = <3300 3300>;
|
||||
spi-max-frequency = <50000000>;
|
||||
};
|
|
@ -81,6 +81,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
|
|||
|
||||
'i' - Send a SIGKILL to all processes, except for init.
|
||||
|
||||
'j' - Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl.
|
||||
|
||||
'k' - Secure Access Key (SAK) Kills all programs on the current virtual
|
||||
console. NOTE: See important comments below in SAK section.
|
||||
|
||||
|
@ -160,6 +162,9 @@ t'E'rm and k'I'll are useful if you have some sort of runaway process you
|
|||
are unable to kill any other way, especially if it's spawning other
|
||||
processes.
|
||||
|
||||
"'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen
|
||||
(probably root) filesystem via the FIFREEZE ioctl.
|
||||
|
||||
* Sometimes SysRq seems to get 'stuck' after using it, what can I do?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
That happens to me, also. I've found that tapping shift, alt, and control
|
||||
|
|
|
@ -135,7 +135,7 @@
|
|||
134 -> Adlink RTV24
|
||||
135 -> DViCO FusionHDTV 5 Lite [18ac:d500]
|
||||
136 -> Acorp Y878F [9511:1540]
|
||||
137 -> Conceptronic CTVFMi v2
|
||||
137 -> Conceptronic CTVFMi v2 [036e:109e]
|
||||
138 -> Prolink Pixelview PV-BT878P+ (Rev.2E)
|
||||
139 -> Prolink PixelView PlayTV MPEG2 PV-M4900
|
||||
140 -> Osprey 440 [0070:ff07]
|
||||
|
@ -154,3 +154,7 @@
|
|||
153 -> PHYTEC VD-012 (bt878)
|
||||
154 -> PHYTEC VD-012-X1 (bt878)
|
||||
155 -> PHYTEC VD-012-X2 (bt878)
|
||||
156 -> IVCE-8784 [0000:f050,0001:f050,0002:f050,0003:f050]
|
||||
157 -> Geovision GV-800(S) (master) [800a:763d]
|
||||
158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d]
|
||||
159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
|
||||
|
|
|
@ -12,3 +12,7 @@
|
|||
11 -> DViCO FusionHDTV DVB-T Dual Express [18ac:db78]
|
||||
12 -> Leadtek Winfast PxDVR3200 H [107d:6681]
|
||||
13 -> Compro VideoMate E650F [185b:e800]
|
||||
14 -> TurboSight TBS 6920 [6920:8888]
|
||||
15 -> TeVii S470 [d470:9022]
|
||||
16 -> DVBWorld DVB-S2 2005 [0001:2005]
|
||||
17 -> NetUP Dual DVB-S2 CI [1b55:2a2c]
|
||||
|
|
|
@ -77,3 +77,4 @@
|
|||
76 -> SATTRADE ST4200 DVB-S/S2 [b200:4200]
|
||||
77 -> TBS 8910 DVB-S [8910:8888]
|
||||
78 -> Prof 6200 DVB-S [b022:3022]
|
||||
79 -> Terratec Cinergy HT PCI MKII [153b:1177]
|
||||
|
|
|
@ -7,12 +7,12 @@
|
|||
6 -> Terratec Cinergy 200 USB (em2800)
|
||||
7 -> Leadtek Winfast USB II (em2800) [0413:6023]
|
||||
8 -> Kworld USB2800 (em2800)
|
||||
9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a]
|
||||
9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,2304:0207,2304:021a]
|
||||
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
|
||||
11 -> Terratec Hybrid XS (em2880) [0ccd:0042]
|
||||
12 -> Kworld PVR TV 2800 RF (em2820/em2840)
|
||||
13 -> Terratec Prodigy XS (em2880) [0ccd:0047]
|
||||
14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
|
||||
14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
|
||||
15 -> V-Gear PocketTV (em2800)
|
||||
16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b]
|
||||
17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227]
|
||||
|
@ -30,7 +30,6 @@
|
|||
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
|
||||
31 -> Usbgear VD204v9 (em2821)
|
||||
32 -> Supercomp USB 2.0 TV (em2821)
|
||||
33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821)
|
||||
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
||||
35 -> Typhoon DVD Maker (em2860)
|
||||
36 -> NetGMBH Cam (em2860)
|
||||
|
@ -58,3 +57,7 @@
|
|||
58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041]
|
||||
60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f]
|
||||
61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840)
|
||||
62 -> Gadmei TVR200 (em2820/em2840)
|
||||
63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303]
|
||||
64 -> Easy Cap Capture DC-60 (em2860)
|
||||
65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515]
|
||||
|
|
|
@ -153,3 +153,5 @@
|
|||
152 -> Asus Tiger Rev:1.00 [1043:4857]
|
||||
153 -> Kworld Plus TV Analog Lite PCI [17de:7128]
|
||||
154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d]
|
||||
155 -> Hauppauge WinTV-HVR1120 ATSC/QAM-Hybrid [0070:6706,0070:6708]
|
||||
156 -> Hauppauge WinTV-HVR1110r3 [0070:6707,0070:6709,0070:670a]
|
||||
|
|
|
@ -401,8 +401,7 @@ Additional notes for software developers:
|
|||
first set the correct norm. Well, it seems logically correct: TV
|
||||
standard is "more constant" for current country than geometry
|
||||
settings of a variety of TV capture cards which may work in ITU or
|
||||
square pixel format. Remember that users now can lock the norm to
|
||||
avoid any ambiguity.
|
||||
square pixel format.
|
||||
--
|
||||
Please note that lavplay/lavrec are also included in the MJPEG-tools
|
||||
(http://mjpeg.sf.net/).
|
||||
|
|
|
@ -81,16 +81,6 @@ tuner.o
|
|||
pal=[bdgil] select PAL variant (used for some tuners
|
||||
only, important for the audio carrier).
|
||||
|
||||
tvmixer.o
|
||||
registers a mixer device for the TV card's volume/bass/treble
|
||||
controls (requires a i2c audio control chip like the msp3400).
|
||||
|
||||
insmod args:
|
||||
debug=1 print some debug info to the syslog.
|
||||
devnr=n allocate device #n (0 == /dev/mixer,
|
||||
1 = /dev/mixer1, ...), default is to
|
||||
use the first free one.
|
||||
|
||||
tvaudio.o
|
||||
new, experimental module which is supported to provide a single
|
||||
driver for all simple i2c audio control chips (tda/tea*).
|
||||
|
|
|
@ -63,8 +63,8 @@ If you have some knowledge and spare time, please try to fix this
|
|||
yourself (patches very welcome of course...) You know: The linux
|
||||
slogan is "Do it yourself".
|
||||
|
||||
There is a mailing list: video4linux-list@redhat.com.
|
||||
https://listman.redhat.com/mailman/listinfo/video4linux-list
|
||||
There is a mailing list: linux-media@vger.kernel.org
|
||||
http://vger.kernel.org/vger-lists.html#linux-media
|
||||
|
||||
If you have trouble with some specific TV card, try to ask there
|
||||
instead of mailing me directly. The chance that someone with the
|
||||
|
|
|
@ -32,6 +32,10 @@ Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
|
|||
The width of a frame is always 720 pixels, regardless of the actual specified
|
||||
width.
|
||||
|
||||
If the height is not a multiple of 32 lines, then the captured video is
|
||||
missing macroblocks at the end and is unusable. So the height must be a
|
||||
multiple of 32.
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
#include <stdio.h>
|
||||
|
|
|
@ -32,6 +32,7 @@ spca561 041e:403b Creative Webcam Vista (VF0010)
|
|||
zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250)
|
||||
ov519 041e:4052 Creative Live! VISTA IM
|
||||
zc3xx 041e:4053 Creative Live!Cam Video IM
|
||||
vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130)
|
||||
ov519 041e:405f Creative Live! VISTA VF0330
|
||||
ov519 041e:4060 Creative Live! VISTA VF0350
|
||||
ov519 041e:4061 Creative Live! VISTA VF0400
|
||||
|
@ -193,6 +194,7 @@ spca500 084d:0003 D-Link DSC-350
|
|||
spca500 08ca:0103 Aiptek PocketDV
|
||||
sunplus 08ca:0104 Aiptek PocketDVII 1.3
|
||||
sunplus 08ca:0106 Aiptek Pocket DV3100+
|
||||
mr97310a 08ca:0111 Aiptek PenCam VGA+
|
||||
sunplus 08ca:2008 Aiptek Mini PenCam 2 M
|
||||
sunplus 08ca:2010 Aiptek PocketCam 3M
|
||||
sunplus 08ca:2016 Aiptek PocketCam 2 Mega
|
||||
|
@ -215,6 +217,7 @@ pac207 093a:2468 PAC207
|
|||
pac207 093a:2470 Genius GF112
|
||||
pac207 093a:2471 Genius VideoCam ge111
|
||||
pac207 093a:2472 Genius VideoCam ge110
|
||||
pac207 093a:2474 Genius iLook 111
|
||||
pac207 093a:2476 Genius e-Messenger 112
|
||||
pac7311 093a:2600 PAC7311 Typhoon
|
||||
pac7311 093a:2601 Philips SPC 610 NC
|
||||
|
@ -279,6 +282,7 @@ spca561 10fd:7e50 FlyCam Usb 100
|
|||
zc3xx 10fd:8050 Typhoon Webshot II USB 300k
|
||||
ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201)
|
||||
pac207 145f:013a Trust WB-1300N
|
||||
vc032x 15b8:6001 HP 2.0 Megapixel
|
||||
vc032x 15b8:6002 HP 2.0 Megapixel rz406aa
|
||||
spca501 1776:501c Arowana 300K CMOS Camera
|
||||
t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers
|
||||
|
||||
Copyright (c) 2008 Tobias Lorenz <tobias.lorenz@gmx.net>
|
||||
Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net>
|
||||
|
||||
|
||||
Information from Silicon Labs
|
||||
|
@ -41,7 +41,7 @@ chips are known to work:
|
|||
- 10c4:818a: Silicon Labs USB FM Radio Reference Design
|
||||
- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF)
|
||||
- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700)
|
||||
- 10c5:819a: DealExtreme USB Radio
|
||||
- 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear)
|
||||
|
||||
|
||||
Software
|
||||
|
@ -52,6 +52,7 @@ Testing is usually done with most application under Debian/testing:
|
|||
- gradio - GTK FM radio tuner
|
||||
- kradio - Comfortable Radio Application for KDE
|
||||
- radio - ncurses-based radio application
|
||||
- mplayer - The Ultimate Movie Player For Linux
|
||||
|
||||
There is also a library libv4l, which can be used. It's going to have a function
|
||||
for frequency seeking, either by using hardware functionality as in radio-si470x
|
||||
|
@ -69,7 +70,7 @@ Audio Listing
|
|||
USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to
|
||||
also select SND_USB_AUDIO, as this is required to get sound from the radio. For
|
||||
listing you have to redirect the sound, for example using one of the following
|
||||
commands.
|
||||
commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x).
|
||||
|
||||
If you just want to test audio (very poor quality):
|
||||
cat /dev/dsp1 > /dev/dsp
|
||||
|
@ -80,6 +81,10 @@ sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
|
|||
If you use arts try:
|
||||
arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
|
||||
|
||||
If you use mplayer try:
|
||||
mplayer -radio adevice=hw=1.0:arate=96000 \
|
||||
-rawaudio rate=96000 \
|
||||
radio://<frequency>/capture
|
||||
|
||||
Module Parameters
|
||||
=================
|
||||
|
|
|
@ -47,7 +47,9 @@ All drivers have the following structure:
|
|||
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
|
||||
/dev/vtxX) and keeping track of device-node specific data.
|
||||
|
||||
4) Filehandle-specific structs containing per-filehandle data.
|
||||
4) Filehandle-specific structs containing per-filehandle data;
|
||||
|
||||
5) video buffer handling.
|
||||
|
||||
This is a rough schematic of how it all relates:
|
||||
|
||||
|
@ -82,12 +84,20 @@ You must register the device instance:
|
|||
v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev);
|
||||
|
||||
Registration will initialize the v4l2_device struct and link dev->driver_data
|
||||
to v4l2_dev. Registration will also set v4l2_dev->name to a value derived from
|
||||
dev (driver name followed by the bus_id, to be precise). You may change the
|
||||
name after registration if you want.
|
||||
to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived
|
||||
from dev (driver name followed by the bus_id, to be precise). If you set it
|
||||
up before calling v4l2_device_register then it will be untouched. If dev is
|
||||
NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register.
|
||||
|
||||
The first 'dev' argument is normally the struct device pointer of a pci_dev,
|
||||
usb_device or platform_device.
|
||||
usb_device or platform_device. It is rare for dev to be NULL, but it happens
|
||||
with ISA devices or when one device creates multiple PCI devices, thus making
|
||||
it impossible to associate v4l2_dev with a particular parent.
|
||||
|
||||
You can also supply a notify() callback that can be called by sub-devices to
|
||||
notify you of events. Whether you need to set this depends on the sub-device.
|
||||
Any notifications a sub-device supports must be defined in a header in
|
||||
include/media/<subdevice>.h.
|
||||
|
||||
You unregister with:
|
||||
|
||||
|
@ -95,6 +105,17 @@ You unregister with:
|
|||
|
||||
Unregistering will also automatically unregister all subdevs from the device.
|
||||
|
||||
If you have a hotpluggable device (e.g. a USB device), then when a disconnect
|
||||
happens the parent device becomes invalid. Since v4l2_device has a pointer to
|
||||
that parent device it has to be cleared as well to mark that the parent is
|
||||
gone. To do this call:
|
||||
|
||||
v4l2_device_disconnect(struct v4l2_device *v4l2_dev);
|
||||
|
||||
This does *not* unregister the subdevs, so you still need to call the
|
||||
v4l2_device_unregister() function for that. If your driver is not hotpluggable,
|
||||
then there is no need to call v4l2_device_disconnect().
|
||||
|
||||
Sometimes you need to iterate over all devices registered by a specific
|
||||
driver. This is usually the case if multiple device drivers use the same
|
||||
hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv
|
||||
|
@ -134,7 +155,7 @@ The recommended approach is as follows:
|
|||
|
||||
static atomic_t drv_instance = ATOMIC_INIT(0);
|
||||
|
||||
static int __devinit drv_probe(struct pci_dev *dev,
|
||||
static int __devinit drv_probe(struct pci_dev *pdev,
|
||||
const struct pci_device_id *pci_id)
|
||||
{
|
||||
...
|
||||
|
@ -218,7 +239,7 @@ to add new ops and categories.
|
|||
|
||||
A sub-device driver initializes the v4l2_subdev struct using:
|
||||
|
||||
v4l2_subdev_init(subdev, &ops);
|
||||
v4l2_subdev_init(sd, &ops);
|
||||
|
||||
Afterwards you need to initialize subdev->name with a unique name and set the
|
||||
module owner. This is done for you if you use the i2c helper functions.
|
||||
|
@ -226,7 +247,7 @@ module owner. This is done for you if you use the i2c helper functions.
|
|||
A device (bridge) driver needs to register the v4l2_subdev with the
|
||||
v4l2_device:
|
||||
|
||||
int err = v4l2_device_register_subdev(device, subdev);
|
||||
int err = v4l2_device_register_subdev(v4l2_dev, sd);
|
||||
|
||||
This can fail if the subdev module disappeared before it could be registered.
|
||||
After this function was called successfully the subdev->dev field points to
|
||||
|
@ -234,17 +255,17 @@ the v4l2_device.
|
|||
|
||||
You can unregister a sub-device using:
|
||||
|
||||
v4l2_device_unregister_subdev(subdev);
|
||||
v4l2_device_unregister_subdev(sd);
|
||||
|
||||
Afterwards the subdev module can be unloaded and subdev->dev == NULL.
|
||||
Afterwards the subdev module can be unloaded and sd->dev == NULL.
|
||||
|
||||
You can call an ops function either directly:
|
||||
|
||||
err = subdev->ops->core->g_chip_ident(subdev, &chip);
|
||||
err = sd->ops->core->g_chip_ident(sd, &chip);
|
||||
|
||||
but it is better and easier to use this macro:
|
||||
|
||||
err = v4l2_subdev_call(subdev, core, g_chip_ident, &chip);
|
||||
err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
|
||||
|
||||
The macro will to the right NULL pointer checks and returns -ENODEV if subdev
|
||||
is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is
|
||||
|
@ -252,19 +273,19 @@ NULL, or the actual result of the subdev->ops->core->g_chip_ident ops.
|
|||
|
||||
It is also possible to call all or a subset of the sub-devices:
|
||||
|
||||
v4l2_device_call_all(dev, 0, core, g_chip_ident, &chip);
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
|
||||
Any subdev that does not support this ops is skipped and error results are
|
||||
ignored. If you want to check for errors use this:
|
||||
|
||||
err = v4l2_device_call_until_err(dev, 0, core, g_chip_ident, &chip);
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
|
||||
Any error except -ENOIOCTLCMD will exit the loop with that error. If no
|
||||
errors (except -ENOIOCTLCMD) occured, then 0 is returned.
|
||||
|
||||
The second argument to both calls is a group ID. If 0, then all subdevs are
|
||||
called. If non-zero, then only those whose group ID match that value will
|
||||
be called. Before a bridge driver registers a subdev it can set subdev->grp_id
|
||||
be called. Before a bridge driver registers a subdev it can set sd->grp_id
|
||||
to whatever value it wants (it's 0 by default). This value is owned by the
|
||||
bridge driver and the sub-device driver will never modify or use it.
|
||||
|
||||
|
@ -276,6 +297,11 @@ e.g. AUDIO_CONTROLLER and specify that as the group ID value when calling
|
|||
v4l2_device_call_all(). That ensures that it will only go to the subdev
|
||||
that needs it.
|
||||
|
||||
If the sub-device needs to notify its v4l2_device parent of an event, then
|
||||
it can call v4l2_subdev_notify(sd, notification, arg). This macro checks
|
||||
whether there is a notify() callback defined and returns -ENODEV if not.
|
||||
Otherwise the result of the notify() call is returned.
|
||||
|
||||
The advantage of using v4l2_subdev is that it is a generic struct and does
|
||||
not contain any knowledge about the underlying hardware. So a driver might
|
||||
contain several subdevs that use an I2C bus, but also a subdev that is
|
||||
|
@ -340,6 +366,12 @@ Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback
|
|||
is called. This will unregister the sub-device from the bridge driver. It is
|
||||
safe to call this even if the sub-device was never registered.
|
||||
|
||||
You need to do this because when the bridge driver destroys the i2c adapter
|
||||
the remove() callbacks are called of the i2c devices on that adapter.
|
||||
After that the corresponding v4l2_subdev structures are invalid, so they
|
||||
have to be unregistered first. Calling v4l2_device_unregister_subdev(sd)
|
||||
from the remove() callback ensures that this is always done correctly.
|
||||
|
||||
|
||||
The bridge driver also has some helper functions it can use:
|
||||
|
||||
|
@ -349,8 +381,8 @@ This loads the given module (can be NULL if no module needs to be loaded) and
|
|||
calls i2c_new_device() with the given i2c_adapter and chip/address arguments.
|
||||
If all goes well, then it registers the subdev with the v4l2_device. It gets
|
||||
the v4l2_device by calling i2c_get_adapdata(adapter), so you should make sure
|
||||
that adapdata is set to v4l2_device when you setup the i2c_adapter in your
|
||||
driver.
|
||||
to call i2c_set_adapdata(adapter, v4l2_device) when you setup the i2c_adapter
|
||||
in your driver.
|
||||
|
||||
You can also use v4l2_i2c_new_probed_subdev() which is very similar to
|
||||
v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses
|
||||
|
@ -358,6 +390,14 @@ that it should probe. Internally it calls i2c_new_probed_device().
|
|||
|
||||
Both functions return NULL if something went wrong.
|
||||
|
||||
Note that the chipid you pass to v4l2_i2c_new_(probed_)subdev() is usually
|
||||
the same as the module name. It allows you to specify a chip variant, e.g.
|
||||
"saa7114" or "saa7115". In general though the i2c driver autodetects this.
|
||||
The use of chipid is something that needs to be looked at more closely at a
|
||||
later date. It differs between i2c drivers and as such can be confusing.
|
||||
To see which chip variants are supported you can look in the i2c driver code
|
||||
for the i2c_device_id table. This lists all the possibilities.
|
||||
|
||||
|
||||
struct video_device
|
||||
-------------------
|
||||
|
@ -396,6 +436,15 @@ You should also set these fields:
|
|||
- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
|
||||
(highly recommended to use this and it might become compulsory in the
|
||||
future!), then set this to your v4l2_ioctl_ops struct.
|
||||
- parent: you only set this if v4l2_device was registered with NULL as
|
||||
the parent device struct. This only happens in cases where one hardware
|
||||
device has multiple PCI devices that all share the same v4l2_device core.
|
||||
|
||||
The cx88 driver is an example of this: one core v4l2_device struct, but
|
||||
it is used by both an raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the v4l2_device cannot be associated with a particular
|
||||
PCI device it is setup without a parent device. But when the struct
|
||||
video_device is setup you do know which parent PCI device to use.
|
||||
|
||||
If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or
|
||||
.ioctl to video_ioctl2 in your v4l2_file_operations struct.
|
||||
|
@ -499,8 +548,8 @@ There are a few useful helper functions:
|
|||
|
||||
You can set/get driver private data in the video_device struct using:
|
||||
|
||||
void *video_get_drvdata(struct video_device *dev);
|
||||
void video_set_drvdata(struct video_device *dev, void *data);
|
||||
void *video_get_drvdata(struct video_device *vdev);
|
||||
void video_set_drvdata(struct video_device *vdev, void *data);
|
||||
|
||||
Note that you can safely call video_set_drvdata() before calling
|
||||
video_register_device().
|
||||
|
@ -519,3 +568,103 @@ void *video_drvdata(struct file *file);
|
|||
You can go from a video_device struct to the v4l2_device struct using:
|
||||
|
||||
struct v4l2_device *v4l2_dev = vdev->v4l2_dev;
|
||||
|
||||
video buffer helper functions
|
||||
-----------------------------
|
||||
|
||||
The v4l2 core API provides a standard method for dealing with video
|
||||
buffers. Those methods allow a driver to implement read(), mmap() and
|
||||
overlay() on a consistent way.
|
||||
|
||||
There are currently methods for using video buffers on devices that
|
||||
supports DMA with scatter/gather method (videobuf-dma-sg), DMA with
|
||||
linear access (videobuf-dma-contig), and vmalloced buffers, mostly
|
||||
used on USB drivers (videobuf-vmalloc).
|
||||
|
||||
Any driver using videobuf should provide operations (callbacks) for
|
||||
four handlers:
|
||||
|
||||
ops->buf_setup - calculates the size of the video buffers and avoid they
|
||||
to waste more than some maximum limit of RAM;
|
||||
ops->buf_prepare - fills the video buffer structs and calls
|
||||
videobuf_iolock() to alloc and prepare mmaped memory;
|
||||
ops->buf_queue - advices the driver that another buffer were
|
||||
requested (by read() or by QBUF);
|
||||
ops->buf_release - frees any buffer that were allocated.
|
||||
|
||||
In order to use it, the driver need to have a code (generally called at
|
||||
interrupt context) that will properly handle the buffer request lists,
|
||||
announcing that a new buffer were filled.
|
||||
|
||||
The irq handling code should handle the videobuf task lists, in order
|
||||
to advice videobuf that a new frame were filled, in order to honor to a
|
||||
request. The code is generally like this one:
|
||||
if (list_empty(&dma_q->active))
|
||||
return;
|
||||
|
||||
buf = list_entry(dma_q->active.next, struct vbuffer, vb.queue);
|
||||
|
||||
if (!waitqueue_active(&buf->vb.done))
|
||||
return;
|
||||
|
||||
/* Some logic to handle the buf may be needed here */
|
||||
|
||||
list_del(&buf->vb.queue);
|
||||
do_gettimeofday(&buf->vb.ts);
|
||||
wake_up(&buf->vb.done);
|
||||
|
||||
Those are the videobuffer functions used on drivers, implemented on
|
||||
videobuf-core:
|
||||
|
||||
- Videobuf init functions
|
||||
videobuf_queue_sg_init()
|
||||
Initializes the videobuf infrastructure. This function should be
|
||||
called before any other videobuf function on drivers that uses DMA
|
||||
Scatter/Gather buffers.
|
||||
|
||||
videobuf_queue_dma_contig_init
|
||||
Initializes the videobuf infrastructure. This function should be
|
||||
called before any other videobuf function on drivers that need DMA
|
||||
contiguous buffers.
|
||||
|
||||
videobuf_queue_vmalloc_init()
|
||||
Initializes the videobuf infrastructure. This function should be
|
||||
called before any other videobuf function on USB (and other drivers)
|
||||
that need a vmalloced type of videobuf.
|
||||
|
||||
- videobuf_iolock()
|
||||
Prepares the videobuf memory for the proper method (read, mmap, overlay).
|
||||
|
||||
- videobuf_queue_is_busy()
|
||||
Checks if a videobuf is streaming.
|
||||
|
||||
- videobuf_queue_cancel()
|
||||
Stops video handling.
|
||||
|
||||
- videobuf_mmap_free()
|
||||
frees mmap buffers.
|
||||
|
||||
- videobuf_stop()
|
||||
Stops video handling, ends mmap and frees mmap and other buffers.
|
||||
|
||||
- V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls:
|
||||
videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(),
|
||||
videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff().
|
||||
|
||||
- V4L1 api function (corresponds to VIDIOCMBUF ioctl):
|
||||
videobuf_cgmbuf()
|
||||
This function is used to provide backward compatibility with V4L1
|
||||
API.
|
||||
|
||||
- Some help functions for read()/poll() operations:
|
||||
videobuf_read_stream()
|
||||
For continuous stream read()
|
||||
videobuf_read_one()
|
||||
For snapshot read()
|
||||
videobuf_poll_stream()
|
||||
polling help function
|
||||
|
||||
The better way to understand it is to take a look at vivi driver. One
|
||||
of the main reasons for vivi is to be a videobuf usage example. the
|
||||
vivi_thread_tick() does the task that the IRQ callback would do on PCI
|
||||
drivers (or the irq callback on USB).
|
||||
|
|
|
@ -105,8 +105,8 @@ int main(int argc, char ** argv)
|
|||
struct video_picture vpic;
|
||||
|
||||
unsigned char *buffer, *src;
|
||||
int bpp = 24, r, g, b;
|
||||
unsigned int i, src_depth;
|
||||
int bpp = 24, r = 0, g = 0, b = 0;
|
||||
unsigned int i, src_depth = 16;
|
||||
|
||||
if (fd < 0) {
|
||||
perror(VIDEO_DEV);
|
||||
|
|
|
@ -65,3 +65,4 @@ Vendor Product Distributor Model
|
|||
0x06d6 0x003b Trust Powerc@m 970Z
|
||||
0x0a17 0x004e Pentax Optio 50
|
||||
0x041e 0x405d Creative DiVi CAM 516
|
||||
0x08ca 0x2102 Aiptek DV T300
|
||||
|
|
101
Documentation/x86/earlyprintk.txt
Normal file
101
Documentation/x86/earlyprintk.txt
Normal file
|
@ -0,0 +1,101 @@
|
|||
|
||||
Mini-HOWTO for using the earlyprintk=dbgp boot option with a
|
||||
USB2 Debug port key and a debug cable, on x86 systems.
|
||||
|
||||
You need two computers, the 'USB debug key' special gadget and
|
||||
and two USB cables, connected like this:
|
||||
|
||||
[host/target] <-------> [USB debug key] <-------> [client/console]
|
||||
|
||||
1. There are three specific hardware requirements:
|
||||
|
||||
a.) Host/target system needs to have USB debug port capability.
|
||||
|
||||
You can check this capability by looking at a 'Debug port' bit in
|
||||
the lspci -vvv output:
|
||||
|
||||
# lspci -vvv
|
||||
...
|
||||
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
|
||||
Subsystem: Lenovo ThinkPad T61
|
||||
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
|
||||
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
|
||||
Latency: 0
|
||||
Interrupt: pin D routed to IRQ 19
|
||||
Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
|
||||
Capabilities: [50] Power Management version 2
|
||||
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
|
||||
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
|
||||
Capabilities: [58] Debug port: BAR=1 offset=00a0
|
||||
^^^^^^^^^^^ <==================== [ HERE ]
|
||||
Kernel driver in use: ehci_hcd
|
||||
Kernel modules: ehci-hcd
|
||||
...
|
||||
|
||||
( If your system does not list a debug port capability then you probably
|
||||
wont be able to use the USB debug key. )
|
||||
|
||||
b.) You also need a Netchip USB debug cable/key:
|
||||
|
||||
http://www.plxtech.com/products/NET2000/NET20DC/default.asp
|
||||
|
||||
This is a small blue plastic connector with two USB connections,
|
||||
it draws power from its USB connections.
|
||||
|
||||
c.) Thirdly, you need a second client/console system with a regular USB port.
|
||||
|
||||
2. Software requirements:
|
||||
|
||||
a.) On the host/target system:
|
||||
|
||||
You need to enable the following kernel config option:
|
||||
|
||||
CONFIG_EARLY_PRINTK_DBGP=y
|
||||
|
||||
And you need to add the boot command line: "earlyprintk=dbgp".
|
||||
(If you are using Grub, append it to the 'kernel' line in
|
||||
/etc/grub.conf)
|
||||
|
||||
NOTE: normally earlyprintk console gets turned off once the
|
||||
regular console is alive - use "earlyprintk=dbgp,keep" to keep
|
||||
this channel open beyond early bootup. This can be useful for
|
||||
debugging crashes under Xorg, etc.
|
||||
|
||||
b.) On the client/console system:
|
||||
|
||||
You should enable the following kernel config option:
|
||||
|
||||
CONFIG_USB_SERIAL_DEBUG=y
|
||||
|
||||
On the next bootup with the modified kernel you should
|
||||
get a /dev/ttyUSBx device(s).
|
||||
|
||||
Now this channel of kernel messages is ready to be used: start
|
||||
your favorite terminal emulator (minicom, etc.) and set
|
||||
it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
|
||||
see the raw output.
|
||||
|
||||
c.) On Nvidia Southbridge based systems: the kernel will try to probe
|
||||
and find out which port has debug device connected.
|
||||
|
||||
3. Testing that it works fine:
|
||||
|
||||
You can test the output by using earlyprintk=dbgp,keep and provoking
|
||||
kernel messages on the host/target system. You can provoke a harmless
|
||||
kernel message by for example doing:
|
||||
|
||||
echo h > /proc/sysrq-trigger
|
||||
|
||||
On the host/target system you should see this help line in "dmesg" output:
|
||||
|
||||
SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)
|
||||
|
||||
On the client/console system do:
|
||||
|
||||
cat /dev/ttyUSB0
|
||||
|
||||
And you should see the help line above displayed shortly after you've
|
||||
provoked it on the host system.
|
||||
|
||||
If it does not work then please ask about it on the linux-kernel@vger.kernel.org
|
||||
mailing list or contact the x86 maintainers.
|
18
MAINTAINERS
18
MAINTAINERS
|
@ -357,6 +357,7 @@ S: Odd Fixes for 2.4; Maintained for 2.6.
|
|||
P: Ivan Kokshaysky
|
||||
M: ink@jurassic.park.msu.ru
|
||||
S: Maintained for 2.4; PCI support for 2.6.
|
||||
L: linux-alpha@vger.kernel.org
|
||||
|
||||
AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
|
||||
P: Thomas Dahlmann
|
||||
|
@ -1063,7 +1064,6 @@ BTTV VIDEO4LINUX DRIVER
|
|||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
@ -2202,25 +2202,12 @@ L: linux-ide@vger.kernel.org
|
|||
T: quilt kernel.org/pub/linux/kernel/people/bart/pata-2.6/
|
||||
S: Maintained
|
||||
|
||||
IDE/ATAPI CDROM DRIVER
|
||||
IDE/ATAPI DRIVERS
|
||||
P: Borislav Petkov
|
||||
M: petkovbb@gmail.com
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
IDE/ATAPI FLOPPY DRIVERS
|
||||
P: Paul Bristow
|
||||
M: Paul Bristow <paul@paulbristow.net>
|
||||
W: http://paulbristow.net/linux/idefloppy.html
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
IDE/ATAPI TAPE DRIVERS
|
||||
P: Gadi Oxman
|
||||
M: Gadi Oxman <gadio@netvision.net.il>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
IDLE-I7300
|
||||
P: Andy Henroid
|
||||
M: andrew.d.henroid@intel.com
|
||||
|
@ -4835,7 +4822,6 @@ VIDEO FOR LINUX (V4L)
|
|||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
|
|
@ -106,3 +106,5 @@ config HAVE_CLK
|
|||
The <linux/clk.h> calls support software clock gating and
|
||||
thus are a key power management tool on many systems.
|
||||
|
||||
config HAVE_DMA_API_DEBUG
|
||||
bool
|
||||
|
|
|
@ -80,7 +80,7 @@ struct alpha_machine_vector
|
|||
void (*update_irq_hw)(unsigned long, unsigned long, int);
|
||||
void (*ack_irq)(unsigned long);
|
||||
void (*device_interrupt)(unsigned long vector);
|
||||
void (*machine_check)(u64 vector, u64 la);
|
||||
void (*machine_check)(unsigned long vector, unsigned long la);
|
||||
|
||||
void (*smp_callin)(void);
|
||||
void (*init_arch)(void);
|
||||
|
|
|
@ -273,4 +273,18 @@ struct pci_dev *alpha_gendev_to_pci(struct device *dev);
|
|||
|
||||
extern struct pci_dev *isa_bridge;
|
||||
|
||||
extern int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val,
|
||||
size_t count);
|
||||
extern int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val,
|
||||
size_t count);
|
||||
extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
|
||||
struct vm_area_struct *vma,
|
||||
enum pci_mmap_state mmap_state);
|
||||
extern void pci_adjust_legacy_attr(struct pci_bus *bus,
|
||||
enum pci_mmap_state mmap_type);
|
||||
#define HAVE_PCI_LEGACY 1
|
||||
|
||||
extern int pci_create_resource_files(struct pci_dev *dev);
|
||||
extern void pci_remove_resource_files(struct pci_dev *dev);
|
||||
|
||||
#endif /* __ALPHA_PCI_H */
|
||||
|
|
|
@ -309,519 +309,72 @@ extern int __min_ipl;
|
|||
#define tbia() __tbi(-2, /* no second argument */)
|
||||
|
||||
/*
|
||||
* Atomic exchange.
|
||||
* Since it can be used to implement critical sections
|
||||
* it must clobber "memory" (also for interrupts in UP).
|
||||
* Atomic exchange routines.
|
||||
*/
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u8(volatile char *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
#define __ASM__MB
|
||||
#define ____xchg(type, args...) __xchg ## type ## _local(args)
|
||||
#define ____cmpxchg(type, args...) __cmpxchg ## type ## _local(args)
|
||||
#include <asm/xchg.h>
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" insbl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extbl %2,%4,%0\n"
|
||||
" mskbl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u16(volatile short *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" inswl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extwl %2,%4,%0\n"
|
||||
" mskwl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u32(volatile int *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u64(volatile long *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
/* This function doesn't exist, so you'll get a linker error
|
||||
if something tries to do an invalid xchg(). */
|
||||
extern void __xchg_called_with_bad_pointer(void);
|
||||
|
||||
#define __xchg(ptr, x, size) \
|
||||
({ \
|
||||
unsigned long __xchg__res; \
|
||||
volatile void *__xchg__ptr = (ptr); \
|
||||
switch (size) { \
|
||||
case 1: __xchg__res = __xchg_u8(__xchg__ptr, x); break; \
|
||||
case 2: __xchg__res = __xchg_u16(__xchg__ptr, x); break; \
|
||||
case 4: __xchg__res = __xchg_u32(__xchg__ptr, x); break; \
|
||||
case 8: __xchg__res = __xchg_u64(__xchg__ptr, x); break; \
|
||||
default: __xchg_called_with_bad_pointer(); __xchg__res = x; \
|
||||
} \
|
||||
__xchg__res; \
|
||||
})
|
||||
|
||||
#define xchg(ptr,x) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _x_ = (x); \
|
||||
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
|
||||
#define xchg_local(ptr,x) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _x_ = (x); \
|
||||
(__typeof__(*(ptr))) __xchg_local((ptr), (unsigned long)_x_, \
|
||||
sizeof(*(ptr))); \
|
||||
})
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u8_local(volatile char *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" insbl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extbl %2,%4,%0\n"
|
||||
" mskbl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u16_local(volatile short *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" inswl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extwl %2,%4,%0\n"
|
||||
" mskwl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u32_local(volatile int *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__xchg_u64_local(volatile long *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
#define __xchg_local(ptr, x, size) \
|
||||
({ \
|
||||
unsigned long __xchg__res; \
|
||||
volatile void *__xchg__ptr = (ptr); \
|
||||
switch (size) { \
|
||||
case 1: __xchg__res = __xchg_u8_local(__xchg__ptr, x); break; \
|
||||
case 2: __xchg__res = __xchg_u16_local(__xchg__ptr, x); break; \
|
||||
case 4: __xchg__res = __xchg_u32_local(__xchg__ptr, x); break; \
|
||||
case 8: __xchg__res = __xchg_u64_local(__xchg__ptr, x); break; \
|
||||
default: __xchg_called_with_bad_pointer(); __xchg__res = x; \
|
||||
} \
|
||||
__xchg__res; \
|
||||
})
|
||||
|
||||
#define xchg_local(ptr,x) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _x_ = (x); \
|
||||
(__typeof__(*(ptr))) __xchg_local((ptr), (unsigned long)_x_, \
|
||||
sizeof(*(ptr))); \
|
||||
#define cmpxchg_local(ptr, o, n) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _o_ = (o); \
|
||||
__typeof__(*(ptr)) _n_ = (n); \
|
||||
(__typeof__(*(ptr))) __cmpxchg_local((ptr), (unsigned long)_o_, \
|
||||
(unsigned long)_n_, \
|
||||
sizeof(*(ptr))); \
|
||||
})
|
||||
|
||||
/*
|
||||
* Atomic compare and exchange. Compare OLD with MEM, if identical,
|
||||
* store NEW in MEM. Return the initial value in MEM. Success is
|
||||
* indicated by comparing RETURN with OLD.
|
||||
*
|
||||
* The memory barrier should be placed in SMP only when we actually
|
||||
* make the change. If we don't change anything (so if the returned
|
||||
* prev is equal to old) then we aren't acquiring anything new and
|
||||
* we don't need any memory barrier as far I can tell.
|
||||
*/
|
||||
#define cmpxchg64_local(ptr, o, n) \
|
||||
({ \
|
||||
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
|
||||
cmpxchg_local((ptr), (o), (n)); \
|
||||
})
|
||||
|
||||
#ifdef CONFIG_SMP
|
||||
#undef __ASM__MB
|
||||
#define __ASM__MB "\tmb\n"
|
||||
#endif
|
||||
#undef ____xchg
|
||||
#undef ____cmpxchg
|
||||
#define ____xchg(type, args...) __xchg ##type(args)
|
||||
#define ____cmpxchg(type, args...) __cmpxchg ##type(args)
|
||||
#include <asm/xchg.h>
|
||||
|
||||
#define xchg(ptr,x) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _x_ = (x); \
|
||||
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, \
|
||||
sizeof(*(ptr))); \
|
||||
})
|
||||
|
||||
#define cmpxchg(ptr, o, n) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _o_ = (o); \
|
||||
__typeof__(*(ptr)) _n_ = (n); \
|
||||
(__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
|
||||
(unsigned long)_n_, sizeof(*(ptr)));\
|
||||
})
|
||||
|
||||
#define cmpxchg64(ptr, o, n) \
|
||||
({ \
|
||||
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
|
||||
cmpxchg((ptr), (o), (n)); \
|
||||
})
|
||||
|
||||
#undef __ASM__MB
|
||||
#undef ____cmpxchg
|
||||
|
||||
#define __HAVE_ARCH_CMPXCHG 1
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u8(volatile char *m, long old, long new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" insbl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extbl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskbl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u16(volatile short *m, long old, long new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" inswl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extwl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskwl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u32(volatile int *m, int old, int new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
#ifdef CONFIG_SMP
|
||||
" mb\n"
|
||||
#endif
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
/* This function doesn't exist, so you'll get a linker error
|
||||
if something tries to do an invalid cmpxchg(). */
|
||||
extern void __cmpxchg_called_with_bad_pointer(void);
|
||||
|
||||
static __always_inline unsigned long
|
||||
__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
|
||||
{
|
||||
switch (size) {
|
||||
case 1:
|
||||
return __cmpxchg_u8(ptr, old, new);
|
||||
case 2:
|
||||
return __cmpxchg_u16(ptr, old, new);
|
||||
case 4:
|
||||
return __cmpxchg_u32(ptr, old, new);
|
||||
case 8:
|
||||
return __cmpxchg_u64(ptr, old, new);
|
||||
}
|
||||
__cmpxchg_called_with_bad_pointer();
|
||||
return old;
|
||||
}
|
||||
|
||||
#define cmpxchg(ptr, o, n) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _o_ = (o); \
|
||||
__typeof__(*(ptr)) _n_ = (n); \
|
||||
(__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
|
||||
(unsigned long)_n_, sizeof(*(ptr))); \
|
||||
})
|
||||
#define cmpxchg64(ptr, o, n) \
|
||||
({ \
|
||||
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
|
||||
cmpxchg((ptr), (o), (n)); \
|
||||
})
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u8_local(volatile char *m, long old, long new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" insbl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extbl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskbl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u16_local(volatile short *m, long old, long new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" inswl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extwl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskwl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u32_local(volatile int *m, int old, int new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
__cmpxchg_u64_local(volatile long *m, unsigned long old, unsigned long new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static __always_inline unsigned long
|
||||
__cmpxchg_local(volatile void *ptr, unsigned long old, unsigned long new,
|
||||
int size)
|
||||
{
|
||||
switch (size) {
|
||||
case 1:
|
||||
return __cmpxchg_u8_local(ptr, old, new);
|
||||
case 2:
|
||||
return __cmpxchg_u16_local(ptr, old, new);
|
||||
case 4:
|
||||
return __cmpxchg_u32_local(ptr, old, new);
|
||||
case 8:
|
||||
return __cmpxchg_u64_local(ptr, old, new);
|
||||
}
|
||||
__cmpxchg_called_with_bad_pointer();
|
||||
return old;
|
||||
}
|
||||
|
||||
#define cmpxchg_local(ptr, o, n) \
|
||||
({ \
|
||||
__typeof__(*(ptr)) _o_ = (o); \
|
||||
__typeof__(*(ptr)) _n_ = (n); \
|
||||
(__typeof__(*(ptr))) __cmpxchg_local((ptr), (unsigned long)_o_, \
|
||||
(unsigned long)_n_, sizeof(*(ptr))); \
|
||||
})
|
||||
#define cmpxchg64_local(ptr, o, n) \
|
||||
({ \
|
||||
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
|
||||
cmpxchg_local((ptr), (o), (n)); \
|
||||
})
|
||||
|
||||
|
||||
#endif /* __ASSEMBLY__ */
|
||||
|
||||
#define arch_align_stack(x) (x)
|
||||
|
|
|
@ -8,7 +8,12 @@
|
|||
* not a major issue. However, for interoperability, libraries still
|
||||
* need to be careful to avoid a name clashes.
|
||||
*/
|
||||
|
||||
#ifdef __KERNEL__
|
||||
#include <asm-generic/int-ll64.h>
|
||||
#else
|
||||
#include <asm-generic/int-l64.h>
|
||||
#endif
|
||||
|
||||
#ifndef __ASSEMBLY__
|
||||
|
||||
|
|
|
@ -498,13 +498,13 @@ struct exception_table_entry
|
|||
};
|
||||
|
||||
/* Returns the new pc */
|
||||
#define fixup_exception(map_reg, fixup, pc) \
|
||||
#define fixup_exception(map_reg, _fixup, pc) \
|
||||
({ \
|
||||
if ((fixup)->fixup.bits.valreg != 31) \
|
||||
map_reg((fixup)->fixup.bits.valreg) = 0; \
|
||||
if ((fixup)->fixup.bits.errreg != 31) \
|
||||
map_reg((fixup)->fixup.bits.errreg) = -EFAULT; \
|
||||
(pc) + (fixup)->fixup.bits.nextinsn; \
|
||||
if ((_fixup)->fixup.bits.valreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.valreg) = 0; \
|
||||
if ((_fixup)->fixup.bits.errreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.errreg) = -EFAULT; \
|
||||
(pc) + (_fixup)->fixup.bits.nextinsn; \
|
||||
})
|
||||
|
||||
|
||||
|
|
258
arch/alpha/include/asm/xchg.h
Normal file
258
arch/alpha/include/asm/xchg.h
Normal file
|
@ -0,0 +1,258 @@
|
|||
#ifndef __ALPHA_SYSTEM_H
|
||||
#error Do not include xchg.h directly!
|
||||
#else
|
||||
/*
|
||||
* xchg/xchg_local and cmpxchg/cmpxchg_local share the same code
|
||||
* except that local version do not have the expensive memory barrier.
|
||||
* So this file is included twice from asm/system.h.
|
||||
*/
|
||||
|
||||
/*
|
||||
* Atomic exchange.
|
||||
* Since it can be used to implement critical sections
|
||||
* it must clobber "memory" (also for interrupts in UP).
|
||||
*/
|
||||
|
||||
static inline unsigned long
|
||||
____xchg(_u8, volatile char *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" insbl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extbl %2,%4,%0\n"
|
||||
" mskbl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
__ASM__MB
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____xchg(_u16, volatile short *m, unsigned long val)
|
||||
{
|
||||
unsigned long ret, tmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %4,7,%3\n"
|
||||
" inswl %1,%4,%1\n"
|
||||
"1: ldq_l %2,0(%3)\n"
|
||||
" extwl %2,%4,%0\n"
|
||||
" mskwl %2,%4,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%3)\n"
|
||||
" beq %2,2f\n"
|
||||
__ASM__MB
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "1" (val) : "memory");
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____xchg(_u32, volatile int *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
__ASM__MB
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____xchg(_u64, volatile long *m, unsigned long val)
|
||||
{
|
||||
unsigned long dummy;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%4\n"
|
||||
" bis $31,%3,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,2f\n"
|
||||
__ASM__MB
|
||||
".subsection 2\n"
|
||||
"2: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (val), "=&r" (dummy), "=m" (*m)
|
||||
: "rI" (val), "m" (*m) : "memory");
|
||||
|
||||
return val;
|
||||
}
|
||||
|
||||
/* This function doesn't exist, so you'll get a linker error
|
||||
if something tries to do an invalid xchg(). */
|
||||
extern void __xchg_called_with_bad_pointer(void);
|
||||
|
||||
static __always_inline unsigned long
|
||||
____xchg(, volatile void *ptr, unsigned long x, int size)
|
||||
{
|
||||
switch (size) {
|
||||
case 1:
|
||||
return ____xchg(_u8, ptr, x);
|
||||
case 2:
|
||||
return ____xchg(_u16, ptr, x);
|
||||
case 4:
|
||||
return ____xchg(_u32, ptr, x);
|
||||
case 8:
|
||||
return ____xchg(_u64, ptr, x);
|
||||
}
|
||||
__xchg_called_with_bad_pointer();
|
||||
return x;
|
||||
}
|
||||
|
||||
/*
|
||||
* Atomic compare and exchange. Compare OLD with MEM, if identical,
|
||||
* store NEW in MEM. Return the initial value in MEM. Success is
|
||||
* indicated by comparing RETURN with OLD.
|
||||
*
|
||||
* The memory barrier should be placed in SMP only when we actually
|
||||
* make the change. If we don't change anything (so if the returned
|
||||
* prev is equal to old) then we aren't acquiring anything new and
|
||||
* we don't need any memory barrier as far I can tell.
|
||||
*/
|
||||
|
||||
static inline unsigned long
|
||||
____cmpxchg(_u8, volatile char *m, unsigned char old, unsigned char new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" insbl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extbl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskbl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
__ASM__MB
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____cmpxchg(_u16, volatile short *m, unsigned short old, unsigned short new)
|
||||
{
|
||||
unsigned long prev, tmp, cmp, addr64;
|
||||
|
||||
__asm__ __volatile__(
|
||||
" andnot %5,7,%4\n"
|
||||
" inswl %1,%5,%1\n"
|
||||
"1: ldq_l %2,0(%4)\n"
|
||||
" extwl %2,%5,%0\n"
|
||||
" cmpeq %0,%6,%3\n"
|
||||
" beq %3,2f\n"
|
||||
" mskwl %2,%5,%2\n"
|
||||
" or %1,%2,%2\n"
|
||||
" stq_c %2,0(%4)\n"
|
||||
" beq %2,3f\n"
|
||||
__ASM__MB
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
|
||||
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____cmpxchg(_u32, volatile int *m, int old, int new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldl_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stl_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
__ASM__MB
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
static inline unsigned long
|
||||
____cmpxchg(_u64, volatile long *m, unsigned long old, unsigned long new)
|
||||
{
|
||||
unsigned long prev, cmp;
|
||||
|
||||
__asm__ __volatile__(
|
||||
"1: ldq_l %0,%5\n"
|
||||
" cmpeq %0,%3,%1\n"
|
||||
" beq %1,2f\n"
|
||||
" mov %4,%1\n"
|
||||
" stq_c %1,%2\n"
|
||||
" beq %1,3f\n"
|
||||
__ASM__MB
|
||||
"2:\n"
|
||||
".subsection 2\n"
|
||||
"3: br 1b\n"
|
||||
".previous"
|
||||
: "=&r"(prev), "=&r"(cmp), "=m"(*m)
|
||||
: "r"((long) old), "r"(new), "m"(*m) : "memory");
|
||||
|
||||
return prev;
|
||||
}
|
||||
|
||||
/* This function doesn't exist, so you'll get a linker error
|
||||
if something tries to do an invalid cmpxchg(). */
|
||||
extern void __cmpxchg_called_with_bad_pointer(void);
|
||||
|
||||
static __always_inline unsigned long
|
||||
____cmpxchg(, volatile void *ptr, unsigned long old, unsigned long new,
|
||||
int size)
|
||||
{
|
||||
switch (size) {
|
||||
case 1:
|
||||
return ____cmpxchg(_u8, ptr, old, new);
|
||||
case 2:
|
||||
return ____cmpxchg(_u16, ptr, old, new);
|
||||
case 4:
|
||||
return ____cmpxchg(_u32, ptr, old, new);
|
||||
case 8:
|
||||
return ____cmpxchg(_u64, ptr, old, new);
|
||||
}
|
||||
__cmpxchg_called_with_bad_pointer();
|
||||
return old;
|
||||
}
|
||||
|
||||
#endif
|
|
@ -12,7 +12,7 @@ obj-y := entry.o traps.o process.o init_task.o osf_sys.o irq.o \
|
|||
|
||||
obj-$(CONFIG_VGA_HOSE) += console.o
|
||||
obj-$(CONFIG_SMP) += smp.o
|
||||
obj-$(CONFIG_PCI) += pci.o pci_iommu.o
|
||||
obj-$(CONFIG_PCI) += pci.o pci_iommu.o pci-sysfs.o
|
||||
obj-$(CONFIG_SRM_ENV) += srm_env.o
|
||||
obj-$(CONFIG_MODULES) += module.o
|
||||
|
||||
|
|
|
@ -157,8 +157,8 @@ ev6_parse_cbox(u64 c_addr, u64 c1_syn, u64 c2_syn,
|
|||
err_print_prefix,
|
||||
streamname[stream], bitsname[bits], sourcename[source]);
|
||||
|
||||
printk("%s Address: 0x%016lx\n"
|
||||
" Syndrome[upper.lower]: %02lx.%02lx\n",
|
||||
printk("%s Address: 0x%016llx\n"
|
||||
" Syndrome[upper.lower]: %02llx.%02llx\n",
|
||||
err_print_prefix,
|
||||
c_addr,
|
||||
c2_syn, c1_syn);
|
||||
|
|
|
@ -246,13 +246,13 @@ ev7_process_pal_subpacket(struct el_subpacket *header)
|
|||
|
||||
switch(header->type) {
|
||||
case EL_TYPE__PAL__LOGOUT_FRAME:
|
||||
printk("%s*** MCHK occurred on LPID %ld (RBOX %lx)\n",
|
||||
printk("%s*** MCHK occurred on LPID %ld (RBOX %llx)\n",
|
||||
err_print_prefix,
|
||||
packet->by_type.logout.whami,
|
||||
packet->by_type.logout.rbox_whami);
|
||||
el_print_timestamp(&packet->by_type.logout.timestamp);
|
||||
printk("%s EXC_ADDR: %016lx\n"
|
||||
" HALT_CODE: %lx\n",
|
||||
printk("%s EXC_ADDR: %016llx\n"
|
||||
" HALT_CODE: %llx\n",
|
||||
err_print_prefix,
|
||||
packet->by_type.logout.exc_addr,
|
||||
packet->by_type.logout.halt_code);
|
||||
|
|
|
@ -129,7 +129,7 @@ marvel_print_po7_crrct_sym(u64 crrct_sym)
|
|||
|
||||
|
||||
printk("%s Correctable Error Symptoms:\n"
|
||||
"%s Syndrome: 0x%lx\n",
|
||||
"%s Syndrome: 0x%llx\n",
|
||||
err_print_prefix,
|
||||
err_print_prefix, EXTRACT(crrct_sym, IO7__PO7_CRRCT_SYM__SYN));
|
||||
marvel_print_err_cyc(EXTRACT(crrct_sym, IO7__PO7_CRRCT_SYM__ERR_CYC));
|
||||
|
@ -186,7 +186,7 @@ marvel_print_po7_uncrr_sym(u64 uncrr_sym, u64 valid_mask)
|
|||
uncrr_sym &= valid_mask;
|
||||
|
||||
if (EXTRACT(valid_mask, IO7__PO7_UNCRR_SYM__SYN))
|
||||
printk("%s Syndrome: 0x%lx\n",
|
||||
printk("%s Syndrome: 0x%llx\n",
|
||||
err_print_prefix,
|
||||
EXTRACT(uncrr_sym, IO7__PO7_UNCRR_SYM__SYN));
|
||||
|
||||
|
@ -307,7 +307,7 @@ marvel_print_po7_ugbge_sym(u64 ugbge_sym)
|
|||
sprintf(opcode_str, "BlkIO");
|
||||
break;
|
||||
default:
|
||||
sprintf(opcode_str, "0x%lx\n",
|
||||
sprintf(opcode_str, "0x%llx\n",
|
||||
EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_OPCODE));
|
||||
break;
|
||||
}
|
||||
|
@ -321,7 +321,7 @@ marvel_print_po7_ugbge_sym(u64 ugbge_sym)
|
|||
opcode_str);
|
||||
|
||||
if (0xC5 != EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_OPCODE))
|
||||
printk("%s Packet Offset 0x%08lx\n",
|
||||
printk("%s Packet Offset 0x%08llx\n",
|
||||
err_print_prefix,
|
||||
EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_PKT_OFF));
|
||||
}
|
||||
|
@ -480,8 +480,8 @@ marvel_print_po7_err_sum(struct ev7_pal_io_subpacket *io)
|
|||
printk("%s Lost Error\n", err_print_prefix);
|
||||
|
||||
printk("%s Failing Packet:\n"
|
||||
"%s Cycle 1: %016lx\n"
|
||||
"%s Cycle 2: %016lx\n",
|
||||
"%s Cycle 1: %016llx\n"
|
||||
"%s Cycle 2: %016llx\n",
|
||||
err_print_prefix,
|
||||
err_print_prefix, io->po7_err_pkt0,
|
||||
err_print_prefix, io->po7_err_pkt1);
|
||||
|
@ -515,9 +515,9 @@ marvel_print_pox_tlb_err(u64 tlb_err)
|
|||
if (!(tlb_err & IO7__POX_TLBERR__ERR_VALID))
|
||||
return;
|
||||
|
||||
printk("%s TLB Error on index 0x%lx:\n"
|
||||
printk("%s TLB Error on index 0x%llx:\n"
|
||||
"%s - %s\n"
|
||||
"%s - Addr: 0x%016lx\n",
|
||||
"%s - Addr: 0x%016llx\n",
|
||||
err_print_prefix,
|
||||
EXTRACT(tlb_err, IO7__POX_TLBERR__ERR_TLB_PTR),
|
||||
err_print_prefix,
|
||||
|
@ -579,7 +579,7 @@ marvel_print_pox_spl_cmplt(u64 spl_cmplt)
|
|||
sprintf(message, "Uncorrectable Split Write Data Error");
|
||||
break;
|
||||
default:
|
||||
sprintf(message, "%08lx\n",
|
||||
sprintf(message, "%08llx\n",
|
||||
EXTRACT(spl_cmplt, IO7__POX_SPLCMPLT__MESSAGE));
|
||||
break;
|
||||
}
|
||||
|
@ -620,9 +620,9 @@ marvel_print_pox_trans_sum(u64 trans_sum)
|
|||
return;
|
||||
|
||||
printk("%s Transaction Summary:\n"
|
||||
"%s Command: 0x%lx - %s\n"
|
||||
"%s Address: 0x%016lx%s\n"
|
||||
"%s PCI-X Master Slot: 0x%lx\n",
|
||||
"%s Command: 0x%llx - %s\n"
|
||||
"%s Address: 0x%016llx%s\n"
|
||||
"%s PCI-X Master Slot: 0x%llx\n",
|
||||
err_print_prefix,
|
||||
err_print_prefix,
|
||||
EXTRACT(trans_sum, IO7__POX_TRANSUM__PCIX_CMD),
|
||||
|
@ -964,12 +964,12 @@ marvel_process_io_error(struct ev7_lf_subpackets *lf_subpackets, int print)
|
|||
|
||||
#if 0
|
||||
printk("%s PORT 7 ERROR:\n"
|
||||
"%s PO7_ERROR_SUM: %016lx\n"
|
||||
"%s PO7_UNCRR_SYM: %016lx\n"
|
||||
"%s PO7_CRRCT_SYM: %016lx\n"
|
||||
"%s PO7_UGBGE_SYM: %016lx\n"
|
||||
"%s PO7_ERR_PKT0: %016lx\n"
|
||||
"%s PO7_ERR_PKT1: %016lx\n",
|
||||
"%s PO7_ERROR_SUM: %016llx\n"
|
||||
"%s PO7_UNCRR_SYM: %016llx\n"
|
||||
"%s PO7_CRRCT_SYM: %016llx\n"
|
||||
"%s PO7_UGBGE_SYM: %016llx\n"
|
||||
"%s PO7_ERR_PKT0: %016llx\n"
|
||||
"%s PO7_ERR_PKT1: %016llx\n",
|
||||
err_print_prefix,
|
||||
err_print_prefix, io->po7_error_sum,
|
||||
err_print_prefix, io->po7_uncrr_sym,
|
||||
|
@ -987,12 +987,12 @@ marvel_process_io_error(struct ev7_lf_subpackets *lf_subpackets, int print)
|
|||
if (!MARVEL_IO_ERR_VALID(io->ports[i].pox_err_sum))
|
||||
continue;
|
||||
|
||||
printk("%s PID %u PORT %d POx_ERR_SUM: %016lx\n",
|
||||
printk("%s PID %u PORT %d POx_ERR_SUM: %016llx\n",
|
||||
err_print_prefix,
|
||||
lf_subpackets->io_pid, i, io->ports[i].pox_err_sum);
|
||||
marvel_print_pox_err(io->ports[i].pox_err_sum, &io->ports[i]);
|
||||
|
||||
printk("%s [ POx_FIRST_ERR: %016lx ]\n",
|
||||
printk("%s [ POx_FIRST_ERR: %016llx ]\n",
|
||||
err_print_prefix, io->ports[i].pox_first_err);
|
||||
marvel_print_pox_err(io->ports[i].pox_first_err,
|
||||
&io->ports[i]);
|
||||
|
|
|
@ -107,12 +107,12 @@ titan_parse_p_serror(int which, u64 serror, int print)
|
|||
if (!print)
|
||||
return status;
|
||||
|
||||
printk("%s PChip %d SERROR: %016lx\n",
|
||||
printk("%s PChip %d SERROR: %016llx\n",
|
||||
err_print_prefix, which, serror);
|
||||
if (serror & TITAN__PCHIP_SERROR__ECCMASK) {
|
||||
printk("%s %sorrectable ECC Error:\n"
|
||||
" Source: %-6s Command: %-8s Syndrome: 0x%08x\n"
|
||||
" Address: 0x%lx\n",
|
||||
" Address: 0x%llx\n",
|
||||
err_print_prefix,
|
||||
(serror & TITAN__PCHIP_SERROR__UECC) ? "Unc" : "C",
|
||||
serror_src[EXTRACT(serror, TITAN__PCHIP_SERROR__SRC)],
|
||||
|
@ -223,7 +223,7 @@ titan_parse_p_perror(int which, int port, u64 perror, int print)
|
|||
if (!print)
|
||||
return status;
|
||||
|
||||
printk("%s PChip %d %cPERROR: %016lx\n",
|
||||
printk("%s PChip %d %cPERROR: %016llx\n",
|
||||
err_print_prefix, which,
|
||||
port ? 'A' : 'G', perror);
|
||||
if (perror & TITAN__PCHIP_PERROR__IPTPW)
|
||||
|
@ -316,7 +316,7 @@ titan_parse_p_agperror(int which, u64 agperror, int print)
|
|||
addr = EXTRACT(agperror, TITAN__PCHIP_AGPERROR__ADDR) << 3;
|
||||
len = EXTRACT(agperror, TITAN__PCHIP_AGPERROR__LEN);
|
||||
|
||||
printk("%s PChip %d AGPERROR: %016lx\n", err_print_prefix,
|
||||
printk("%s PChip %d AGPERROR: %016llx\n", err_print_prefix,
|
||||
which, agperror);
|
||||
if (agperror & TITAN__PCHIP_AGPERROR__NOWINDOW)
|
||||
printk("%s No Window\n", err_print_prefix);
|
||||
|
@ -597,16 +597,16 @@ privateer_process_680_frame(struct el_common *mchk_header, int print)
|
|||
return status;
|
||||
|
||||
/* TODO - decode instead of just dumping... */
|
||||
printk("%s Summary Flags: %016lx\n"
|
||||
" CChip DIRx: %016lx\n"
|
||||
" System Management IR: %016lx\n"
|
||||
" CPU IR: %016lx\n"
|
||||
" Power Supply IR: %016lx\n"
|
||||
" LM78 Fault Status: %016lx\n"
|
||||
" System Doors: %016lx\n"
|
||||
" Temperature Warning: %016lx\n"
|
||||
" Fan Control: %016lx\n"
|
||||
" Fatal Power Down Code: %016lx\n",
|
||||
printk("%s Summary Flags: %016llx\n"
|
||||
" CChip DIRx: %016llx\n"
|
||||
" System Management IR: %016llx\n"
|
||||
" CPU IR: %016llx\n"
|
||||
" Power Supply IR: %016llx\n"
|
||||
" LM78 Fault Status: %016llx\n"
|
||||
" System Doors: %016llx\n"
|
||||
" Temperature Warning: %016llx\n"
|
||||
" Fan Control: %016llx\n"
|
||||
" Fatal Power Down Code: %016llx\n",
|
||||
err_print_prefix,
|
||||
emchk->summary,
|
||||
emchk->c_dirx,
|
||||
|
|
366
arch/alpha/kernel/pci-sysfs.c
Normal file
366
arch/alpha/kernel/pci-sysfs.c
Normal file
|
@ -0,0 +1,366 @@
|
|||
/*
|
||||
* arch/alpha/kernel/pci-sysfs.c
|
||||
*
|
||||
* Copyright (C) 2009 Ivan Kokshaysky
|
||||
*
|
||||
* Alpha PCI resource files.
|
||||
*
|
||||
* Loosely based on generic HAVE_PCI_MMAP implementation in
|
||||
* drivers/pci/pci-sysfs.c
|
||||
*/
|
||||
|
||||
#include <linux/sched.h>
|
||||
#include <linux/pci.h>
|
||||
|
||||
static int hose_mmap_page_range(struct pci_controller *hose,
|
||||
struct vm_area_struct *vma,
|
||||
enum pci_mmap_state mmap_type, int sparse)
|
||||
{
|
||||
unsigned long base;
|
||||
|
||||
if (mmap_type == pci_mmap_mem)
|
||||
base = sparse ? hose->sparse_mem_base : hose->dense_mem_base;
|
||||
else
|
||||
base = sparse ? hose->sparse_io_base : hose->dense_io_base;
|
||||
|
||||
vma->vm_pgoff += base >> PAGE_SHIFT;
|
||||
vma->vm_flags |= (VM_IO | VM_RESERVED);
|
||||
|
||||
return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
|
||||
vma->vm_end - vma->vm_start,
|
||||
vma->vm_page_prot);
|
||||
}
|
||||
|
||||
static int __pci_mmap_fits(struct pci_dev *pdev, int num,
|
||||
struct vm_area_struct *vma, int sparse)
|
||||
{
|
||||
unsigned long nr, start, size;
|
||||
int shift = sparse ? 5 : 0;
|
||||
|
||||
nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
|
||||
start = vma->vm_pgoff;
|
||||
size = ((pci_resource_len(pdev, num) - 1) >> (PAGE_SHIFT - shift)) + 1;
|
||||
|
||||
if (start < size && size - start >= nr)
|
||||
return 1;
|
||||
WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on %s BAR %d "
|
||||
"(size 0x%08lx)\n",
|
||||
current->comm, sparse ? " sparse" : "", start, start + nr,
|
||||
pci_name(pdev), num, size);
|
||||
return 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* pci_mmap_resource - map a PCI resource into user memory space
|
||||
* @kobj: kobject for mapping
|
||||
* @attr: struct bin_attribute for the file being mapped
|
||||
* @vma: struct vm_area_struct passed into the mmap
|
||||
* @sparse: address space type
|
||||
*
|
||||
* Use the bus mapping routines to map a PCI resource into userspace.
|
||||
*/
|
||||
static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
|
||||
struct vm_area_struct *vma, int sparse)
|
||||
{
|
||||
struct pci_dev *pdev = to_pci_dev(container_of(kobj,
|
||||
struct device, kobj));
|
||||
struct resource *res = (struct resource *)attr->private;
|
||||
enum pci_mmap_state mmap_type;
|
||||
struct pci_bus_region bar;
|
||||
int i;
|
||||
|
||||
for (i = 0; i < PCI_ROM_RESOURCE; i++)
|
||||
if (res == &pdev->resource[i])
|
||||
break;
|
||||
if (i >= PCI_ROM_RESOURCE)
|
||||
return -ENODEV;
|
||||
|
||||
if (!__pci_mmap_fits(pdev, i, vma, sparse))
|
||||
return -EINVAL;
|
||||
|
||||
if (iomem_is_exclusive(res->start))
|
||||
return -EINVAL;
|
||||
|
||||
pcibios_resource_to_bus(pdev, &bar, res);
|
||||
vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
|
||||
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
|
||||
|
||||
return hose_mmap_page_range(pdev->sysdata, vma, mmap_type, sparse);
|
||||
}
|
||||
|
||||
static int pci_mmap_resource_sparse(struct kobject *kobj,
|
||||
struct bin_attribute *attr,
|
||||
struct vm_area_struct *vma)
|
||||
{
|
||||
return pci_mmap_resource(kobj, attr, vma, 1);
|
||||
}
|
||||
|
||||
static int pci_mmap_resource_dense(struct kobject *kobj,
|
||||
struct bin_attribute *attr,
|
||||
struct vm_area_struct *vma)
|
||||
{
|
||||
return pci_mmap_resource(kobj, attr, vma, 0);
|
||||
}
|
||||
|
||||
/**
|
||||
* pci_remove_resource_files - cleanup resource files
|
||||
* @dev: dev to cleanup
|
||||
*
|
||||
* If we created resource files for @dev, remove them from sysfs and
|
||||
* free their resources.
|
||||
*/
|
||||
void pci_remove_resource_files(struct pci_dev *pdev)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; i < PCI_ROM_RESOURCE; i++) {
|
||||
struct bin_attribute *res_attr;
|
||||
|
||||
res_attr = pdev->res_attr[i];
|
||||
if (res_attr) {
|
||||
sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
|
||||
kfree(res_attr);
|
||||
}
|
||||
|
||||
res_attr = pdev->res_attr_wc[i];
|
||||
if (res_attr) {
|
||||
sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
|
||||
kfree(res_attr);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
|
||||
{
|
||||
struct pci_bus_region bar;
|
||||
struct pci_controller *hose = pdev->sysdata;
|
||||
long dense_offset;
|
||||
unsigned long sparse_size;
|
||||
|
||||
pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]);
|
||||
|
||||
/* All core logic chips have 4G sparse address space, except
|
||||
CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
|
||||
definitions in asm/core_xxx.h files). This corresponds
|
||||
to 128M or 512M of the bus space. */
|
||||
dense_offset = (long)(hose->dense_mem_base - hose->sparse_mem_base);
|
||||
sparse_size = dense_offset >= 0x400000000UL ? 0x20000000 : 0x8000000;
|
||||
|
||||
return bar.end < sparse_size;
|
||||
}
|
||||
|
||||
static int pci_create_one_attr(struct pci_dev *pdev, int num, char *name,
|
||||
char *suffix, struct bin_attribute *res_attr,
|
||||
unsigned long sparse)
|
||||
{
|
||||
size_t size = pci_resource_len(pdev, num);
|
||||
|
||||
sprintf(name, "resource%d%s", num, suffix);
|
||||
res_attr->mmap = sparse ? pci_mmap_resource_sparse :
|
||||
pci_mmap_resource_dense;
|
||||
res_attr->attr.name = name;
|
||||
res_attr->attr.mode = S_IRUSR | S_IWUSR;
|
||||
res_attr->size = sparse ? size << 5 : size;
|
||||
res_attr->private = &pdev->resource[num];
|
||||
return sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
|
||||
}
|
||||
|
||||
static int pci_create_attr(struct pci_dev *pdev, int num)
|
||||
{
|
||||
/* allocate attribute structure, piggyback attribute name */
|
||||
int retval, nlen1, nlen2 = 0, res_count = 1;
|
||||
unsigned long sparse_base, dense_base;
|
||||
struct bin_attribute *attr;
|
||||
struct pci_controller *hose = pdev->sysdata;
|
||||
char *suffix, *attr_name;
|
||||
|
||||
suffix = ""; /* Assume bwx machine, normal resourceN files. */
|
||||
nlen1 = 10;
|
||||
|
||||
if (pdev->resource[num].flags & IORESOURCE_MEM) {
|
||||
sparse_base = hose->sparse_mem_base;
|
||||
dense_base = hose->dense_mem_base;
|
||||
if (sparse_base && !sparse_mem_mmap_fits(pdev, num)) {
|
||||
sparse_base = 0;
|
||||
suffix = "_dense";
|
||||
nlen1 = 16; /* resourceN_dense */
|
||||
}
|
||||
} else {
|
||||
sparse_base = hose->sparse_io_base;
|
||||
dense_base = hose->dense_io_base;
|
||||
}
|
||||
|
||||
if (sparse_base) {
|
||||
suffix = "_sparse";
|
||||
nlen1 = 17;
|
||||
if (dense_base) {
|
||||
nlen2 = 16; /* resourceN_dense */
|
||||
res_count = 2;
|
||||
}
|
||||
}
|
||||
|
||||
attr = kzalloc(sizeof(*attr) * res_count + nlen1 + nlen2, GFP_ATOMIC);
|
||||
if (!attr)
|
||||
return -ENOMEM;
|
||||
|
||||
/* Create bwx, sparse or single dense file */
|
||||
attr_name = (char *)(attr + res_count);
|
||||
pdev->res_attr[num] = attr;
|
||||
retval = pci_create_one_attr(pdev, num, attr_name, suffix, attr,
|
||||
sparse_base);
|
||||
if (retval || res_count == 1)
|
||||
return retval;
|
||||
|
||||
/* Create dense file */
|
||||
attr_name += nlen1;
|
||||
attr++;
|
||||
pdev->res_attr_wc[num] = attr;
|
||||
return pci_create_one_attr(pdev, num, attr_name, "_dense", attr, 0);
|
||||
}
|
||||
|
||||
/**
|
||||
* pci_create_resource_files - create resource files in sysfs for @dev
|
||||
* @dev: dev in question
|
||||
*
|
||||
* Walk the resources in @dev creating files for each resource available.
|
||||
*/
|
||||
int pci_create_resource_files(struct pci_dev *pdev)
|
||||
{
|
||||
int i;
|
||||
int retval;
|
||||
|
||||
/* Expose the PCI resources from this device as files */
|
||||
for (i = 0; i < PCI_ROM_RESOURCE; i++) {
|
||||
|
||||
/* skip empty resources */
|
||||
if (!pci_resource_len(pdev, i))
|
||||
continue;
|
||||
|
||||
retval = pci_create_attr(pdev, i);
|
||||
if (retval) {
|
||||
pci_remove_resource_files(pdev);
|
||||
return retval;
|
||||
}
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* Legacy I/O bus mapping stuff. */
|
||||
|
||||
static int __legacy_mmap_fits(struct pci_controller *hose,
|
||||
struct vm_area_struct *vma,
|
||||
unsigned long res_size, int sparse)
|
||||
{
|
||||
unsigned long nr, start, size;
|
||||
|
||||
nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
|
||||
start = vma->vm_pgoff;
|
||||
size = ((res_size - 1) >> PAGE_SHIFT) + 1;
|
||||
|
||||
if (start < size && size - start >= nr)
|
||||
return 1;
|
||||
WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on hose %d "
|
||||
"(size 0x%08lx)\n",
|
||||
current->comm, sparse ? " sparse" : "", start, start + nr,
|
||||
hose->index, size);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static inline int has_sparse(struct pci_controller *hose,
|
||||
enum pci_mmap_state mmap_type)
|
||||
{
|
||||
unsigned long base;
|
||||
|
||||
base = (mmap_type == pci_mmap_mem) ? hose->sparse_mem_base :
|
||||
hose->sparse_io_base;
|
||||
|
||||
return base != 0;
|
||||
}
|
||||
|
||||
int pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma,
|
||||
enum pci_mmap_state mmap_type)
|
||||
{
|
||||
struct pci_controller *hose = bus->sysdata;
|
||||
int sparse = has_sparse(hose, mmap_type);
|
||||
unsigned long res_size;
|
||||
|
||||
res_size = (mmap_type == pci_mmap_mem) ? bus->legacy_mem->size :
|
||||
bus->legacy_io->size;
|
||||
if (!__legacy_mmap_fits(hose, vma, res_size, sparse))
|
||||
return -EINVAL;
|
||||
|
||||
return hose_mmap_page_range(hose, vma, mmap_type, sparse);
|
||||
}
|
||||
|
||||
/**
|
||||
* pci_adjust_legacy_attr - adjustment of legacy file attributes
|
||||
* @b: bus to create files under
|
||||
* @mmap_type: I/O port or memory
|
||||
*
|
||||
* Adjust file name and size for sparse mappings.
|
||||
*/
|
||||
void pci_adjust_legacy_attr(struct pci_bus *bus, enum pci_mmap_state mmap_type)
|
||||
{
|
||||
struct pci_controller *hose = bus->sysdata;
|
||||
|
||||
if (!has_sparse(hose, mmap_type))
|
||||
return;
|
||||
|
||||
if (mmap_type == pci_mmap_mem) {
|
||||
bus->legacy_mem->attr.name = "legacy_mem_sparse";
|
||||
bus->legacy_mem->size <<= 5;
|
||||
} else {
|
||||
bus->legacy_io->attr.name = "legacy_io_sparse";
|
||||
bus->legacy_io->size <<= 5;
|
||||
}
|
||||
return;
|
||||
}
|
||||
|
||||
/* Legacy I/O bus read/write functions */
|
||||
int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val, size_t size)
|
||||
{
|
||||
struct pci_controller *hose = bus->sysdata;
|
||||
|
||||
port += hose->io_space->start;
|
||||
|
||||
switch(size) {
|
||||
case 1:
|
||||
*((u8 *)val) = inb(port);
|
||||
return 1;
|
||||
case 2:
|
||||
if (port & 1)
|
||||
return -EINVAL;
|
||||
*((u16 *)val) = inw(port);
|
||||
return 2;
|
||||
case 4:
|
||||
if (port & 3)
|
||||
return -EINVAL;
|
||||
*((u32 *)val) = inl(port);
|
||||
return 4;
|
||||
}
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val, size_t size)
|
||||
{
|
||||
struct pci_controller *hose = bus->sysdata;
|
||||
|
||||
port += hose->io_space->start;
|
||||
|
||||
switch(size) {
|
||||
case 1:
|
||||
outb(port, val);
|
||||
return 1;
|
||||
case 2:
|
||||
if (port & 1)
|
||||
return -EINVAL;
|
||||
outw(port, val);
|
||||
return 2;
|
||||
case 4:
|
||||
if (port & 3)
|
||||
return -EINVAL;
|
||||
outl(port, val);
|
||||
return 4;
|
||||
}
|
||||
return -EINVAL;
|
||||
}
|
|
@ -168,7 +168,7 @@ pcibios_align_resource(void *data, struct resource *res,
|
|||
*/
|
||||
|
||||
/* Align to multiple of size of minimum base. */
|
||||
alignto = max(0x1000UL, align);
|
||||
alignto = max_t(resource_size_t, 0x1000, align);
|
||||
start = ALIGN(start, alignto);
|
||||
if (hose->sparse_mem_base && size <= 7 * 16*MB) {
|
||||
if (((start / (16*MB)) & 0x7) == 0) {
|
||||
|
|
|
@ -247,7 +247,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
|
|||
&& paddr + size <= __direct_map_size) {
|
||||
ret = paddr + __direct_map_base;
|
||||
|
||||
DBGA2("pci_map_single: [%p,%lx] -> direct %lx from %p\n",
|
||||
DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %p\n",
|
||||
cpu_addr, size, ret, __builtin_return_address(0));
|
||||
|
||||
return ret;
|
||||
|
@ -258,7 +258,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
|
|||
if (dac_allowed) {
|
||||
ret = paddr + alpha_mv.pci_dac_offset;
|
||||
|
||||
DBGA2("pci_map_single: [%p,%lx] -> DAC %lx from %p\n",
|
||||
DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %p\n",
|
||||
cpu_addr, size, ret, __builtin_return_address(0));
|
||||
|
||||
return ret;
|
||||
|
@ -299,7 +299,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
|
|||
ret = arena->dma_base + dma_ofs * PAGE_SIZE;
|
||||
ret += (unsigned long)cpu_addr & ~PAGE_MASK;
|
||||
|
||||
DBGA2("pci_map_single: [%p,%lx] np %ld -> sg %lx from %p\n",
|
||||
DBGA2("pci_map_single: [%p,%zx] np %ld -> sg %llx from %p\n",
|
||||
cpu_addr, size, npages, ret, __builtin_return_address(0));
|
||||
|
||||
return ret;
|
||||
|
@ -355,14 +355,14 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size,
|
|||
&& dma_addr < __direct_map_base + __direct_map_size) {
|
||||
/* Nothing to do. */
|
||||
|
||||
DBGA2("pci_unmap_single: direct [%lx,%lx] from %p\n",
|
||||
DBGA2("pci_unmap_single: direct [%llx,%zx] from %p\n",
|
||||
dma_addr, size, __builtin_return_address(0));
|
||||
|
||||
return;
|
||||
}
|
||||
|
||||
if (dma_addr > 0xffffffff) {
|
||||
DBGA2("pci64_unmap_single: DAC [%lx,%lx] from %p\n",
|
||||
DBGA2("pci64_unmap_single: DAC [%llx,%zx] from %p\n",
|
||||
dma_addr, size, __builtin_return_address(0));
|
||||
return;
|
||||
}
|
||||
|
@ -373,9 +373,9 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size,
|
|||
|
||||
dma_ofs = (dma_addr - arena->dma_base) >> PAGE_SHIFT;
|
||||
if (dma_ofs * PAGE_SIZE >= arena->size) {
|
||||
printk(KERN_ERR "Bogus pci_unmap_single: dma_addr %lx "
|
||||
" base %lx size %x\n", dma_addr, arena->dma_base,
|
||||
arena->size);
|
||||
printk(KERN_ERR "Bogus pci_unmap_single: dma_addr %llx "
|
||||
" base %llx size %x\n",
|
||||
dma_addr, arena->dma_base, arena->size);
|
||||
return;
|
||||
BUG();
|
||||
}
|
||||
|
@ -394,7 +394,7 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size,
|
|||
|
||||
spin_unlock_irqrestore(&arena->lock, flags);
|
||||
|
||||
DBGA2("pci_unmap_single: sg [%lx,%lx] np %ld from %p\n",
|
||||
DBGA2("pci_unmap_single: sg [%llx,%zx] np %ld from %p\n",
|
||||
dma_addr, size, npages, __builtin_return_address(0));
|
||||
}
|
||||
EXPORT_SYMBOL(pci_unmap_single);
|
||||
|
@ -444,7 +444,7 @@ try_again:
|
|||
goto try_again;
|
||||
}
|
||||
|
||||
DBGA2("pci_alloc_consistent: %lx -> [%p,%x] from %p\n",
|
||||
DBGA2("pci_alloc_consistent: %zx -> [%p,%llx] from %p\n",
|
||||
size, cpu_addr, *dma_addrp, __builtin_return_address(0));
|
||||
|
||||
return cpu_addr;
|
||||
|
@ -464,7 +464,7 @@ pci_free_consistent(struct pci_dev *pdev, size_t size, void *cpu_addr,
|
|||
pci_unmap_single(pdev, dma_addr, size, PCI_DMA_BIDIRECTIONAL);
|
||||
free_pages((unsigned long)cpu_addr, get_order(size));
|
||||
|
||||
DBGA2("pci_free_consistent: [%x,%lx] from %p\n",
|
||||
DBGA2("pci_free_consistent: [%llx,%zx] from %p\n",
|
||||
dma_addr, size, __builtin_return_address(0));
|
||||
}
|
||||
EXPORT_SYMBOL(pci_free_consistent);
|
||||
|
@ -551,7 +551,7 @@ sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist *end,
|
|||
out->dma_address = paddr + __direct_map_base;
|
||||
out->dma_length = size;
|
||||
|
||||
DBGA(" sg_fill: [%p,%lx] -> direct %lx\n",
|
||||
DBGA(" sg_fill: [%p,%lx] -> direct %llx\n",
|
||||
__va(paddr), size, out->dma_address);
|
||||
|
||||
return 0;
|
||||
|
@ -563,7 +563,7 @@ sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist *end,
|
|||
out->dma_address = paddr + alpha_mv.pci_dac_offset;
|
||||
out->dma_length = size;
|
||||
|
||||
DBGA(" sg_fill: [%p,%lx] -> DAC %lx\n",
|
||||
DBGA(" sg_fill: [%p,%lx] -> DAC %llx\n",
|
||||
__va(paddr), size, out->dma_address);
|
||||
|
||||
return 0;
|
||||
|
@ -589,7 +589,7 @@ sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist *end,
|
|||
out->dma_address = arena->dma_base + dma_ofs*PAGE_SIZE + paddr;
|
||||
out->dma_length = size;
|
||||
|
||||
DBGA(" sg_fill: [%p,%lx] -> sg %lx np %ld\n",
|
||||
DBGA(" sg_fill: [%p,%lx] -> sg %llx np %ld\n",
|
||||
__va(paddr), size, out->dma_address, npages);
|
||||
|
||||
/* All virtually contiguous. We need to find the length of each
|
||||
|
@ -752,7 +752,7 @@ pci_unmap_sg(struct pci_dev *pdev, struct scatterlist *sg, int nents,
|
|||
|
||||
if (addr > 0xffffffff) {
|
||||
/* It's a DAC address -- nothing to do. */
|
||||
DBGA(" (%ld) DAC [%lx,%lx]\n",
|
||||
DBGA(" (%ld) DAC [%llx,%zx]\n",
|
||||
sg - end + nents, addr, size);
|
||||
continue;
|
||||
}
|
||||
|
@ -760,12 +760,12 @@ pci_unmap_sg(struct pci_dev *pdev, struct scatterlist *sg, int nents,
|
|||
if (addr >= __direct_map_base
|
||||
&& addr < __direct_map_base + __direct_map_size) {
|
||||
/* Nothing to do. */
|
||||
DBGA(" (%ld) direct [%lx,%lx]\n",
|
||||
DBGA(" (%ld) direct [%llx,%zx]\n",
|
||||
sg - end + nents, addr, size);
|
||||
continue;
|
||||
}
|
||||
|
||||
DBGA(" (%ld) sg [%lx,%lx]\n",
|
||||
DBGA(" (%ld) sg [%llx,%zx]\n",
|
||||
sg - end + nents, addr, size);
|
||||
|
||||
npages = iommu_num_pages(addr, size, PAGE_SIZE);
|
||||
|
|
|
@ -20,7 +20,7 @@ struct pci_controller;
|
|||
extern struct pci_ops apecs_pci_ops;
|
||||
extern void apecs_init_arch(void);
|
||||
extern void apecs_pci_clr_err(void);
|
||||
extern void apecs_machine_check(u64, u64);
|
||||
extern void apecs_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void apecs_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_cia.c */
|
||||
|
@ -29,7 +29,7 @@ extern void cia_init_pci(void);
|
|||
extern void cia_init_arch(void);
|
||||
extern void pyxis_init_arch(void);
|
||||
extern void cia_kill_arch(int);
|
||||
extern void cia_machine_check(u64, u64);
|
||||
extern void cia_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void cia_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_irongate.c */
|
||||
|
@ -42,7 +42,7 @@ extern void irongate_machine_check(u64, u64);
|
|||
/* core_lca.c */
|
||||
extern struct pci_ops lca_pci_ops;
|
||||
extern void lca_init_arch(void);
|
||||
extern void lca_machine_check(u64, u64);
|
||||
extern void lca_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void lca_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_marvel.c */
|
||||
|
@ -64,7 +64,7 @@ void io7_clear_errors(struct io7 *io7);
|
|||
extern struct pci_ops mcpcia_pci_ops;
|
||||
extern void mcpcia_init_arch(void);
|
||||
extern void mcpcia_init_hoses(void);
|
||||
extern void mcpcia_machine_check(u64, u64);
|
||||
extern void mcpcia_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void mcpcia_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_polaris.c */
|
||||
|
@ -72,14 +72,14 @@ extern struct pci_ops polaris_pci_ops;
|
|||
extern int polaris_read_config_dword(struct pci_dev *, int, u32 *);
|
||||
extern int polaris_write_config_dword(struct pci_dev *, int, u32);
|
||||
extern void polaris_init_arch(void);
|
||||
extern void polaris_machine_check(u64, u64);
|
||||
extern void polaris_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
#define polaris_pci_tbi ((void *)0)
|
||||
|
||||
/* core_t2.c */
|
||||
extern struct pci_ops t2_pci_ops;
|
||||
extern void t2_init_arch(void);
|
||||
extern void t2_kill_arch(int);
|
||||
extern void t2_machine_check(u64, u64);
|
||||
extern void t2_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void t2_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_titan.c */
|
||||
|
@ -94,14 +94,14 @@ extern struct _alpha_agp_info *titan_agp_info(void);
|
|||
extern struct pci_ops tsunami_pci_ops;
|
||||
extern void tsunami_init_arch(void);
|
||||
extern void tsunami_kill_arch(int);
|
||||
extern void tsunami_machine_check(u64, u64);
|
||||
extern void tsunami_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void tsunami_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
|
||||
/* core_wildfire.c */
|
||||
extern struct pci_ops wildfire_pci_ops;
|
||||
extern void wildfire_init_arch(void);
|
||||
extern void wildfire_kill_arch(int);
|
||||
extern void wildfire_machine_check(u64, u64);
|
||||
extern void wildfire_machine_check(unsigned long vector, unsigned long la_ptr);
|
||||
extern void wildfire_pci_tbi(struct pci_controller *, dma_addr_t, dma_addr_t);
|
||||
extern int wildfire_pa_to_nid(unsigned long);
|
||||
extern int wildfire_cpuid_to_nid(int);
|
||||
|
|
|
@ -1255,7 +1255,7 @@ show_cpuinfo(struct seq_file *f, void *slot)
|
|||
platform_string(), nr_processors);
|
||||
|
||||
#ifdef CONFIG_SMP
|
||||
seq_printf(f, "cpus active\t\t: %d\n"
|
||||
seq_printf(f, "cpus active\t\t: %u\n"
|
||||
"cpu active mask\t\t: %016lx\n",
|
||||
num_online_cpus(), cpus_addr(cpu_possible_map)[0]);
|
||||
#endif
|
||||
|
|
|
@ -2542,8 +2542,8 @@ void __init SMC669_Init ( int index )
|
|||
SMC37c669_display_device_info( );
|
||||
#endif
|
||||
local_irq_restore(flags);
|
||||
printk( "SMC37c669 Super I/O Controller found @ 0x%lx\n",
|
||||
(unsigned long) SMC_base );
|
||||
printk( "SMC37c669 Super I/O Controller found @ 0x%p\n",
|
||||
SMC_base );
|
||||
}
|
||||
else {
|
||||
local_irq_restore(flags);
|
||||
|
|
|
@ -218,7 +218,6 @@ srm_env_init(void)
|
|||
BASE_DIR);
|
||||
goto cleanup;
|
||||
}
|
||||
base_dir->owner = THIS_MODULE;
|
||||
|
||||
/*
|
||||
* Create per-name subdirectory
|
||||
|
@ -229,7 +228,6 @@ srm_env_init(void)
|
|||
BASE_DIR, NAMED_DIR);
|
||||
goto cleanup;
|
||||
}
|
||||
named_dir->owner = THIS_MODULE;
|
||||
|
||||
/*
|
||||
* Create per-number subdirectory
|
||||
|
@ -241,7 +239,6 @@ srm_env_init(void)
|
|||
goto cleanup;
|
||||
|
||||
}
|
||||
numbered_dir->owner = THIS_MODULE;
|
||||
|
||||
/*
|
||||
* Create all named nodes
|
||||
|
@ -254,7 +251,6 @@ srm_env_init(void)
|
|||
goto cleanup;
|
||||
|
||||
entry->proc_entry->data = (void *) entry;
|
||||
entry->proc_entry->owner = THIS_MODULE;
|
||||
entry->proc_entry->read_proc = srm_env_read;
|
||||
entry->proc_entry->write_proc = srm_env_write;
|
||||
|
||||
|
@ -275,7 +271,6 @@ srm_env_init(void)
|
|||
|
||||
entry->id = var_num;
|
||||
entry->proc_entry->data = (void *) entry;
|
||||
entry->proc_entry->owner = THIS_MODULE;
|
||||
entry->proc_entry->read_proc = srm_env_read;
|
||||
entry->proc_entry->write_proc = srm_env_write;
|
||||
}
|
||||
|
|
|
@ -244,12 +244,11 @@ jensen_init_arch(void)
|
|||
}
|
||||
|
||||
static void
|
||||
jensen_machine_check (u64 vector, u64 la)
|
||||
jensen_machine_check(unsigned long vector, unsigned long la)
|
||||
{
|
||||
printk(KERN_CRIT "Machine check\n");
|
||||
}
|
||||
|
||||
|
||||
/*
|
||||
* The System Vector
|
||||
*/
|
||||
|
|
|
@ -453,7 +453,7 @@ sable_lynx_enable_irq(unsigned int irq)
|
|||
sable_lynx_irq_swizzle->update_irq_hw(bit, mask);
|
||||
spin_unlock(&sable_lynx_irq_lock);
|
||||
#if 0
|
||||
printk("%s: mask 0x%lx bit 0x%x irq 0x%x\n",
|
||||
printk("%s: mask 0x%lx bit 0x%lx irq 0x%x\n",
|
||||
__func__, mask, bit, irq);
|
||||
#endif
|
||||
}
|
||||
|
@ -469,7 +469,7 @@ sable_lynx_disable_irq(unsigned int irq)
|
|||
sable_lynx_irq_swizzle->update_irq_hw(bit, mask);
|
||||
spin_unlock(&sable_lynx_irq_lock);
|
||||
#if 0
|
||||
printk("%s: mask 0x%lx bit 0x%x irq 0x%x\n",
|
||||
printk("%s: mask 0x%lx bit 0x%lx irq 0x%x\n",
|
||||
__func__, mask, bit, irq);
|
||||
#endif
|
||||
}
|
||||
|
|
|
@ -623,7 +623,7 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
}
|
||||
|
||||
lock_kernel();
|
||||
printk("Bad unaligned kernel access at %016lx: %p %lx %ld\n",
|
||||
printk("Bad unaligned kernel access at %016lx: %p %lx %lu\n",
|
||||
pc, va, opcode, reg);
|
||||
do_exit(SIGSEGV);
|
||||
|
||||
|
|
|
@ -474,14 +474,34 @@ CONFIG_NETDEVICES=y
|
|||
# CONFIG_EQUALIZER is not set
|
||||
# CONFIG_TUN is not set
|
||||
# CONFIG_VETH is not set
|
||||
# CONFIG_PHYLIB is not set
|
||||
CONFIG_PHYLIB=y
|
||||
|
||||
#
|
||||
# MII PHY device drivers
|
||||
#
|
||||
# CONFIG_MARVELL_PHY is not set
|
||||
# CONFIG_DAVICOM_PHY is not set
|
||||
# CONFIG_QSEMI_PHY is not set
|
||||
# CONFIG_LXT_PHY is not set
|
||||
# CONFIG_CICADA_PHY is not set
|
||||
# CONFIG_VITESSE_PHY is not set
|
||||
CONFIG_SMSC_PHY=y
|
||||
# CONFIG_BROADCOM_PHY is not set
|
||||
# CONFIG_ICPLUS_PHY is not set
|
||||
# CONFIG_REALTEK_PHY is not set
|
||||
# CONFIG_NATIONAL_PHY is not set
|
||||
# CONFIG_STE10XP is not set
|
||||
# CONFIG_LSI_ET1011C_PHY is not set
|
||||
# CONFIG_FIXED_PHY is not set
|
||||
# CONFIG_MDIO_BITBANG is not set
|
||||
CONFIG_NET_ETHERNET=y
|
||||
CONFIG_MII=y
|
||||
# CONFIG_AX88796 is not set
|
||||
# CONFIG_SMC91X is not set
|
||||
# CONFIG_DM9000 is not set
|
||||
# CONFIG_ENC28J60 is not set
|
||||
CONFIG_SMC911X=y
|
||||
# CONFIG_SMC911X is not set
|
||||
CONFIG_SMSC911X=y
|
||||
# CONFIG_IBM_NEW_EMAC_ZMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_RGMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_TAH is not set
|
||||
|
|
|
@ -465,12 +465,33 @@ CONFIG_NETDEVICES=y
|
|||
# CONFIG_EQUALIZER is not set
|
||||
# CONFIG_TUN is not set
|
||||
# CONFIG_VETH is not set
|
||||
# CONFIG_PHYLIB is not set
|
||||
CONFIG_PHYLIB=y
|
||||
|
||||
#
|
||||
# MII PHY device drivers
|
||||
#
|
||||
# CONFIG_MARVELL_PHY is not set
|
||||
# CONFIG_DAVICOM_PHY is not set
|
||||
# CONFIG_QSEMI_PHY is not set
|
||||
# CONFIG_LXT_PHY is not set
|
||||
# CONFIG_CICADA_PHY is not set
|
||||
# CONFIG_VITESSE_PHY is not set
|
||||
CONFIG_SMSC_PHY=y
|
||||
# CONFIG_BROADCOM_PHY is not set
|
||||
# CONFIG_ICPLUS_PHY is not set
|
||||
# CONFIG_REALTEK_PHY is not set
|
||||
# CONFIG_NATIONAL_PHY is not set
|
||||
# CONFIG_STE10XP is not set
|
||||
# CONFIG_LSI_ET1011C_PHY is not set
|
||||
# CONFIG_FIXED_PHY is not set
|
||||
# CONFIG_MDIO_BITBANG is not set
|
||||
CONFIG_NET_ETHERNET=y
|
||||
CONFIG_MII=y
|
||||
# CONFIG_AX88796 is not set
|
||||
CONFIG_SMC91X=y
|
||||
# CONFIG_DM9000 is not set
|
||||
# CONFIG_SMC911X is not set
|
||||
CONFIG_SMSC911X=y
|
||||
# CONFIG_IBM_NEW_EMAC_ZMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_RGMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_TAH is not set
|
||||
|
|
|
@ -496,13 +496,33 @@ CONFIG_NETDEVICES=y
|
|||
# CONFIG_EQUALIZER is not set
|
||||
# CONFIG_TUN is not set
|
||||
# CONFIG_VETH is not set
|
||||
# CONFIG_PHYLIB is not set
|
||||
CONFIG_PHYLIB=y
|
||||
|
||||
#
|
||||
# MII PHY device drivers
|
||||
#
|
||||
# CONFIG_MARVELL_PHY is not set
|
||||
# CONFIG_DAVICOM_PHY is not set
|
||||
# CONFIG_QSEMI_PHY is not set
|
||||
# CONFIG_LXT_PHY is not set
|
||||
# CONFIG_CICADA_PHY is not set
|
||||
# CONFIG_VITESSE_PHY is not set
|
||||
CONFIG_SMSC_PHY=y
|
||||
# CONFIG_BROADCOM_PHY is not set
|
||||
# CONFIG_ICPLUS_PHY is not set
|
||||
# CONFIG_REALTEK_PHY is not set
|
||||
# CONFIG_NATIONAL_PHY is not set
|
||||
# CONFIG_STE10XP is not set
|
||||
# CONFIG_LSI_ET1011C_PHY is not set
|
||||
# CONFIG_FIXED_PHY is not set
|
||||
# CONFIG_MDIO_BITBANG is not set
|
||||
CONFIG_NET_ETHERNET=y
|
||||
CONFIG_MII=y
|
||||
# CONFIG_AX88796 is not set
|
||||
CONFIG_SMC91X=y
|
||||
# CONFIG_DM9000 is not set
|
||||
CONFIG_SMC911X=y
|
||||
# CONFIG_SMC911X is not set
|
||||
CONFIG_SMSC911X=y
|
||||
# CONFIG_IBM_NEW_EMAC_ZMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_RGMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_TAH is not set
|
||||
|
|
|
@ -490,13 +490,33 @@ CONFIG_NETDEVICES=y
|
|||
# CONFIG_EQUALIZER is not set
|
||||
# CONFIG_TUN is not set
|
||||
# CONFIG_VETH is not set
|
||||
# CONFIG_PHYLIB is not set
|
||||
CONFIG_PHYLIB=y
|
||||
|
||||
#
|
||||
# MII PHY device drivers
|
||||
#
|
||||
# CONFIG_MARVELL_PHY is not set
|
||||
# CONFIG_DAVICOM_PHY is not set
|
||||
# CONFIG_QSEMI_PHY is not set
|
||||
# CONFIG_LXT_PHY is not set
|
||||
# CONFIG_CICADA_PHY is not set
|
||||
# CONFIG_VITESSE_PHY is not set
|
||||
CONFIG_SMSC_PHY=y
|
||||
# CONFIG_BROADCOM_PHY is not set
|
||||
# CONFIG_ICPLUS_PHY is not set
|
||||
# CONFIG_REALTEK_PHY is not set
|
||||
# CONFIG_NATIONAL_PHY is not set
|
||||
# CONFIG_STE10XP is not set
|
||||
# CONFIG_LSI_ET1011C_PHY is not set
|
||||
# CONFIG_FIXED_PHY is not set
|
||||
# CONFIG_MDIO_BITBANG is not set
|
||||
CONFIG_NET_ETHERNET=y
|
||||
CONFIG_MII=y
|
||||
# CONFIG_AX88796 is not set
|
||||
CONFIG_SMC91X=y
|
||||
# CONFIG_DM9000 is not set
|
||||
CONFIG_SMC911X=y
|
||||
# CONFIG_SMC911X is not set
|
||||
CONFIG_SMSC911X=y
|
||||
# CONFIG_IBM_NEW_EMAC_ZMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_RGMII is not set
|
||||
# CONFIG_IBM_NEW_EMAC_TAH is not set
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
#include <linux/mtd/plat-ram.h>
|
||||
#include <linux/memory.h>
|
||||
#include <linux/gpio.h>
|
||||
#include <linux/smc911x.h>
|
||||
#include <linux/smsc911x.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/i2c.h>
|
||||
#include <linux/i2c/at24.h>
|
||||
|
@ -70,7 +70,7 @@ static struct imxuart_platform_data uart_pdata = {
|
|||
.flags = IMXUART_HAVE_RTSCTS,
|
||||
};
|
||||
|
||||
static struct resource smc911x_resources[] = {
|
||||
static struct resource smsc911x_resources[] = {
|
||||
[0] = {
|
||||
.start = CS1_BASE_ADDR + 0x300,
|
||||
.end = CS1_BASE_ADDR + 0x300 + SZ_64K - 1,
|
||||
|
@ -79,22 +79,25 @@ static struct resource smc911x_resources[] = {
|
|||
[1] = {
|
||||
.start = IOMUX_TO_IRQ(MX31_PIN_GPIO3_1),
|
||||
.end = IOMUX_TO_IRQ(MX31_PIN_GPIO3_1),
|
||||
.flags = IORESOURCE_IRQ,
|
||||
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
|
||||
},
|
||||
};
|
||||
|
||||
static struct smc911x_platdata smc911x_info = {
|
||||
.flags = SMC911X_USE_32BIT,
|
||||
.irq_flags = IRQF_SHARED | IRQF_TRIGGER_LOW,
|
||||
static struct smsc911x_platform_config smsc911x_info = {
|
||||
.flags = SMSC911X_USE_32BIT | SMSC911X_FORCE_INTERNAL_PHY |
|
||||
SMSC911X_SAVE_MAC_ADDRESS,
|
||||
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
|
||||
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
|
||||
.phy_interface = PHY_INTERFACE_MODE_MII,
|
||||
};
|
||||
|
||||
static struct platform_device pcm037_eth = {
|
||||
.name = "smc911x",
|
||||
.name = "smsc911x",
|
||||
.id = -1,
|
||||
.num_resources = ARRAY_SIZE(smc911x_resources),
|
||||
.resource = smc911x_resources,
|
||||
.num_resources = ARRAY_SIZE(smsc911x_resources),
|
||||
.resource = smsc911x_resources,
|
||||
.dev = {
|
||||
.platform_data = &smc911x_info,
|
||||
.platform_data = &smsc911x_info,
|
||||
},
|
||||
};
|
||||
|
||||
|
|
|
@ -23,6 +23,7 @@
|
|||
#include <linux/spi/ads7846.h>
|
||||
#include <linux/i2c/twl4030.h>
|
||||
#include <linux/io.h>
|
||||
#include <linux/smsc911x.h>
|
||||
|
||||
#include <mach/hardware.h>
|
||||
#include <asm/mach-types.h>
|
||||
|
@ -41,12 +42,12 @@
|
|||
|
||||
#include "mmc-twl4030.h"
|
||||
|
||||
#define LDP_SMC911X_CS 1
|
||||
#define LDP_SMC911X_GPIO 152
|
||||
#define LDP_SMSC911X_CS 1
|
||||
#define LDP_SMSC911X_GPIO 152
|
||||
#define DEBUG_BASE 0x08000000
|
||||
#define LDP_ETHR_START DEBUG_BASE
|
||||
|
||||
static struct resource ldp_smc911x_resources[] = {
|
||||
static struct resource ldp_smsc911x_resources[] = {
|
||||
[0] = {
|
||||
.start = LDP_ETHR_START,
|
||||
.end = LDP_ETHR_START + SZ_4K,
|
||||
|
@ -59,40 +60,50 @@ static struct resource ldp_smc911x_resources[] = {
|
|||
},
|
||||
};
|
||||
|
||||
static struct platform_device ldp_smc911x_device = {
|
||||
.name = "smc911x",
|
||||
static struct smsc911x_platform_config ldp_smsc911x_config = {
|
||||
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
|
||||
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
|
||||
.flags = SMSC911X_USE_32BIT,
|
||||
.phy_interface = PHY_INTERFACE_MODE_MII,
|
||||
};
|
||||
|
||||
static struct platform_device ldp_smsc911x_device = {
|
||||
.name = "smsc911x",
|
||||
.id = -1,
|
||||
.num_resources = ARRAY_SIZE(ldp_smc911x_resources),
|
||||
.resource = ldp_smc911x_resources,
|
||||
.num_resources = ARRAY_SIZE(ldp_smsc911x_resources),
|
||||
.resource = ldp_smsc911x_resources,
|
||||
.dev = {
|
||||
.platform_data = &ldp_smsc911x_config,
|
||||
},
|
||||
};
|
||||
|
||||
static struct platform_device *ldp_devices[] __initdata = {
|
||||
&ldp_smc911x_device,
|
||||
&ldp_smsc911x_device,
|
||||
};
|
||||
|
||||
static inline void __init ldp_init_smc911x(void)
|
||||
static inline void __init ldp_init_smsc911x(void)
|
||||
{
|
||||
int eth_cs;
|
||||
unsigned long cs_mem_base;
|
||||
int eth_gpio = 0;
|
||||
|
||||
eth_cs = LDP_SMC911X_CS;
|
||||
eth_cs = LDP_SMSC911X_CS;
|
||||
|
||||
if (gpmc_cs_request(eth_cs, SZ_16M, &cs_mem_base) < 0) {
|
||||
printk(KERN_ERR "Failed to request GPMC mem for smc911x\n");
|
||||
printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
|
||||
return;
|
||||
}
|
||||
|
||||
ldp_smc911x_resources[0].start = cs_mem_base + 0x0;
|
||||
ldp_smc911x_resources[0].end = cs_mem_base + 0xff;
|
||||
ldp_smsc911x_resources[0].start = cs_mem_base + 0x0;
|
||||
ldp_smsc911x_resources[0].end = cs_mem_base + 0xff;
|
||||
udelay(100);
|
||||
|
||||
eth_gpio = LDP_SMC911X_GPIO;
|
||||
eth_gpio = LDP_SMSC911X_GPIO;
|
||||
|
||||
ldp_smc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
|
||||
ldp_smsc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
|
||||
|
||||
if (gpio_request(eth_gpio, "smc911x irq") < 0) {
|
||||
printk(KERN_ERR "Failed to request GPIO%d for smc911x IRQ\n",
|
||||
if (gpio_request(eth_gpio, "smsc911x irq") < 0) {
|
||||
printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
|
||||
eth_gpio);
|
||||
return;
|
||||
}
|
||||
|
@ -104,7 +115,7 @@ static void __init omap_ldp_init_irq(void)
|
|||
omap2_init_common_hw(NULL);
|
||||
omap_init_irq();
|
||||
omap_gpio_init();
|
||||
ldp_init_smc911x();
|
||||
ldp_init_smsc911x();
|
||||
}
|
||||
|
||||
static struct omap_uart_config ldp_uart_config __initdata = {
|
||||
|
|
|
@ -57,6 +57,9 @@
|
|||
#define GPMC_CS0_BASE 0x60
|
||||
#define GPMC_CS_SIZE 0x30
|
||||
|
||||
#define OVERO_SMSC911X_CS 5
|
||||
#define OVERO_SMSC911X_GPIO 176
|
||||
|
||||
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
|
||||
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
|
||||
|
||||
|
@ -116,6 +119,67 @@ static void __init overo_ads7846_init(void)
|
|||
static inline void __init overo_ads7846_init(void) { return; }
|
||||
#endif
|
||||
|
||||
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
|
||||
|
||||
#include <linux/smsc911x.h>
|
||||
|
||||
static struct resource overo_smsc911x_resources[] = {
|
||||
{
|
||||
.name = "smsc911x-memory",
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
|
||||
},
|
||||
};
|
||||
|
||||
static struct smsc911x_platform_config overo_smsc911x_config = {
|
||||
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
|
||||
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
|
||||
.flags = SMSC911X_USE_32BIT ,
|
||||
.phy_interface = PHY_INTERFACE_MODE_MII,
|
||||
};
|
||||
|
||||
static struct platform_device overo_smsc911x_device = {
|
||||
.name = "smsc911x",
|
||||
.id = -1,
|
||||
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
|
||||
.resource = &overo_smsc911x_resources,
|
||||
.dev = {
|
||||
.platform_data = &overo_smsc911x_config,
|
||||
},
|
||||
};
|
||||
|
||||
static inline void __init overo_init_smsc911x(void)
|
||||
{
|
||||
unsigned long cs_mem_base;
|
||||
|
||||
if (gpmc_cs_request(OVERO_SMSC911X_CS, SZ_16M, &cs_mem_base) < 0) {
|
||||
printk(KERN_ERR "Failed request for GPMC mem for smsc911x\n");
|
||||
return;
|
||||
}
|
||||
|
||||
overo_smsc911x_resources[0].start = cs_mem_base + 0x0;
|
||||
overo_smsc911x_resources[0].end = cs_mem_base + 0xff;
|
||||
|
||||
if ((gpio_request(OVERO_SMSC911X_GPIO, "SMSC911X IRQ") == 0) &&
|
||||
(gpio_direction_input(OVERO_SMSC911X_GPIO) == 0)) {
|
||||
gpio_export(OVERO_SMSC911X_GPIO, 0);
|
||||
} else {
|
||||
printk(KERN_ERR "could not obtain gpio for SMSC911X IRQ\n");
|
||||
return;
|
||||
}
|
||||
|
||||
overo_smsc911x_resources[1].start = OMAP_GPIO_IRQ(OVERO_SMSC911X_GPIO);
|
||||
overo_smsc911x_resources[1].end = 0;
|
||||
|
||||
platform_device_register(&overo_smsc911x_device);
|
||||
}
|
||||
|
||||
#else
|
||||
static inline void __init overo_init_smsc911x(void) { return; }
|
||||
#endif
|
||||
|
||||
static struct mtd_partition overo_nand_partitions[] = {
|
||||
{
|
||||
.name = "xloader",
|
||||
|
@ -290,6 +354,7 @@ static void __init overo_init(void)
|
|||
overo_flash_init();
|
||||
usb_musb_init();
|
||||
overo_ads7846_init();
|
||||
overo_init_smsc911x();
|
||||
|
||||
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
|
||||
"OVERO_GPIO_W2W_NRESET") == 0) &&
|
||||
|
|
|
@ -380,14 +380,49 @@ static struct pca953x_platform_data pca9536_data = {
|
|||
.gpio_base = NR_BUILTIN_GPIO + 1,
|
||||
};
|
||||
|
||||
static struct soc_camera_link iclink[] = {
|
||||
{
|
||||
.bus_id = 0, /* Must match with the camera ID above */
|
||||
.gpio = NR_BUILTIN_GPIO + 1,
|
||||
}, {
|
||||
.bus_id = 0, /* Must match with the camera ID above */
|
||||
.gpio = -ENXIO,
|
||||
static int gpio_bus_switch;
|
||||
|
||||
static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
|
||||
unsigned long flags)
|
||||
{
|
||||
if (gpio_bus_switch <= 0) {
|
||||
if (flags == SOCAM_DATAWIDTH_10)
|
||||
return 0;
|
||||
else
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
if (flags & SOCAM_DATAWIDTH_8)
|
||||
gpio_set_value(gpio_bus_switch, 1);
|
||||
else
|
||||
gpio_set_value(gpio_bus_switch, 0);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link *link)
|
||||
{
|
||||
int ret;
|
||||
|
||||
if (!gpio_bus_switch) {
|
||||
ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
|
||||
if (!ret) {
|
||||
gpio_bus_switch = NR_BUILTIN_GPIO + 1;
|
||||
gpio_direction_output(gpio_bus_switch, 0);
|
||||
} else
|
||||
gpio_bus_switch = -EINVAL;
|
||||
}
|
||||
|
||||
if (gpio_bus_switch > 0)
|
||||
return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
|
||||
else
|
||||
return SOCAM_DATAWIDTH_10;
|
||||
}
|
||||
|
||||
static struct soc_camera_link iclink = {
|
||||
.bus_id = 0, /* Must match with the camera ID above */
|
||||
.query_bus_param = pcm990_camera_query_bus_param,
|
||||
.set_bus_param = pcm990_camera_set_bus_param,
|
||||
};
|
||||
|
||||
/* Board I2C devices. */
|
||||
|
@ -398,10 +433,10 @@ static struct i2c_board_info __initdata pcm990_i2c_devices[] = {
|
|||
.platform_data = &pca9536_data,
|
||||
}, {
|
||||
I2C_BOARD_INFO("mt9v022", 0x48),
|
||||
.platform_data = &iclink[0], /* With extender */
|
||||
.platform_data = &iclink, /* With extender */
|
||||
}, {
|
||||
I2C_BOARD_INFO("mt9m001", 0x5d),
|
||||
.platform_data = &iclink[0], /* With extender */
|
||||
.platform_data = &iclink, /* With extender */
|
||||
},
|
||||
};
|
||||
#endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
#include <linux/clocksource.h>
|
||||
#include <linux/clockchips.h>
|
||||
#include <linux/io.h>
|
||||
#include <linux/smc911x.h>
|
||||
#include <linux/smsc911x.h>
|
||||
#include <linux/ata_platform.h>
|
||||
|
||||
#include <asm/clkdev.h>
|
||||
|
@ -128,14 +128,15 @@ int realview_flash_register(struct resource *res, u32 num)
|
|||
return platform_device_register(&realview_flash_device);
|
||||
}
|
||||
|
||||
static struct smc911x_platdata realview_smc911x_platdata = {
|
||||
.flags = SMC911X_USE_32BIT,
|
||||
.irq_flags = IRQF_SHARED,
|
||||
.irq_polarity = 1,
|
||||
static struct smsc911x_platform_config smsc911x_config = {
|
||||
.flags = SMSC911X_USE_32BIT,
|
||||
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
|
||||
.irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL,
|
||||
.phy_interface = PHY_INTERFACE_MODE_MII,
|
||||
};
|
||||
|
||||
static struct platform_device realview_eth_device = {
|
||||
.name = "smc911x",
|
||||
.name = "smsc911x",
|
||||
.id = 0,
|
||||
.num_resources = 2,
|
||||
};
|
||||
|
@ -145,8 +146,8 @@ int realview_eth_register(const char *name, struct resource *res)
|
|||
if (name)
|
||||
realview_eth_device.name = name;
|
||||
realview_eth_device.resource = res;
|
||||
if (strcmp(realview_eth_device.name, "smc911x") == 0)
|
||||
realview_eth_device.dev.platform_data = &realview_smc911x_platdata;
|
||||
if (strcmp(realview_eth_device.name, "smsc911x") == 0)
|
||||
realview_eth_device.dev.platform_data = &smsc911x_config;
|
||||
|
||||
return platform_device_register(&realview_eth_device);
|
||||
}
|
||||
|
|
52
arch/arm/plat-mxc/include/mach/mx3_camera.h
Normal file
52
arch/arm/plat-mxc/include/mach/mx3_camera.h
Normal file
|
@ -0,0 +1,52 @@
|
|||
/*
|
||||
* mx3_camera.h - i.MX3x camera driver header file
|
||||
*
|
||||
* Copyright (C) 2008, Guennadi Liakhovetski, DENX Software Engineering, <lg@denx.de>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
|
||||
#ifndef _MX3_CAMERA_H_
|
||||
#define _MX3_CAMERA_H_
|
||||
|
||||
#include <linux/device.h>
|
||||
|
||||
#define MX3_CAMERA_CLK_SRC 1
|
||||
#define MX3_CAMERA_EXT_VSYNC 2
|
||||
#define MX3_CAMERA_DP 4
|
||||
#define MX3_CAMERA_PCP 8
|
||||
#define MX3_CAMERA_HSP 0x10
|
||||
#define MX3_CAMERA_VSP 0x20
|
||||
#define MX3_CAMERA_DATAWIDTH_4 0x40
|
||||
#define MX3_CAMERA_DATAWIDTH_8 0x80
|
||||
#define MX3_CAMERA_DATAWIDTH_10 0x100
|
||||
#define MX3_CAMERA_DATAWIDTH_15 0x200
|
||||
|
||||
#define MX3_CAMERA_DATAWIDTH_MASK (MX3_CAMERA_DATAWIDTH_4 | MX3_CAMERA_DATAWIDTH_8 | \
|
||||
MX3_CAMERA_DATAWIDTH_10 | MX3_CAMERA_DATAWIDTH_15)
|
||||
|
||||
/**
|
||||
* struct mx3_camera_pdata - i.MX3x camera platform data
|
||||
* @flags: MX3_CAMERA_* flags
|
||||
* @mclk_10khz: master clock frequency in 10kHz units
|
||||
* @dma_dev: IPU DMA device to match against in channel allocation
|
||||
*/
|
||||
struct mx3_camera_pdata {
|
||||
unsigned long flags;
|
||||
unsigned long mclk_10khz;
|
||||
struct device *dma_dev;
|
||||
};
|
||||
|
||||
#endif
|
|
@ -250,21 +250,3 @@ asmlinkage void do_bus_error(unsigned long addr, int write_access,
|
|||
dump_dtlb();
|
||||
die("Bus Error", regs, SIGKILL);
|
||||
}
|
||||
|
||||
/*
|
||||
* This functionality is currently not possible to implement because
|
||||
* we're using segmentation to ensure a fixed mapping of the kernel
|
||||
* virtual address space.
|
||||
*
|
||||
* It would be possible to implement this, but it would require us to
|
||||
* disable segmentation at startup and load the kernel mappings into
|
||||
* the TLB like any other pages. There will be lots of trickery to
|
||||
* avoid recursive invocation of the TLB miss handler, though...
|
||||
*/
|
||||
#ifdef CONFIG_DEBUG_PAGEALLOC
|
||||
void kernel_map_pages(struct page *page, int numpages, int enable)
|
||||
{
|
||||
|
||||
}
|
||||
EXPORT_SYMBOL(kernel_map_pages);
|
||||
#endif
|
||||
|
|
|
@ -854,7 +854,6 @@ static int __init sram_proc_init(void)
|
|||
printk(KERN_WARNING "unable to create /proc/sram\n");
|
||||
return -1;
|
||||
}
|
||||
ptr->owner = THIS_MODULE;
|
||||
ptr->read_proc = sram_proc_read;
|
||||
return 0;
|
||||
}
|
||||
|
|
|
@ -261,7 +261,6 @@ timer_interrupt(int irq, void *dev_id)
|
|||
static struct irqaction irq2 = {
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_SHARED | IRQF_DISABLED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "timer",
|
||||
};
|
||||
|
||||
|
|
|
@ -65,7 +65,6 @@ static int send_ipi(int vector, int wait, cpumask_t cpu_mask);
|
|||
static struct irqaction irq_ipi = {
|
||||
.handler = crisv32_ipi_interrupt,
|
||||
.flags = IRQF_DISABLED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "ipi",
|
||||
};
|
||||
|
||||
|
|
|
@ -267,7 +267,6 @@ timer_interrupt(int irq, void *dev_id)
|
|||
static struct irqaction irq_timer = {
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_SHARED | IRQF_DISABLED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "timer"
|
||||
};
|
||||
|
||||
|
|
|
@ -109,28 +109,24 @@ static struct irqaction fpga_irq[4] = {
|
|||
[0] = {
|
||||
.handler = fpga_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "fpga.0",
|
||||
.dev_id = (void *) 0x0028UL,
|
||||
},
|
||||
[1] = {
|
||||
.handler = fpga_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "fpga.1",
|
||||
.dev_id = (void *) 0x0050UL,
|
||||
},
|
||||
[2] = {
|
||||
.handler = fpga_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "fpga.2",
|
||||
.dev_id = (void *) 0x1c00UL,
|
||||
},
|
||||
[3] = {
|
||||
.handler = fpga_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "fpga.3",
|
||||
.dev_id = (void *) 0x6386UL,
|
||||
}
|
||||
|
|
|
@ -108,7 +108,6 @@ static struct irqaction fpga_irq[1] = {
|
|||
[0] = {
|
||||
.handler = fpga_interrupt,
|
||||
.flags = IRQF_DISABLED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "fpga.0",
|
||||
.dev_id = (void *) 0x0700UL,
|
||||
}
|
||||
|
|
|
@ -120,14 +120,12 @@ static struct irqaction mb93493_irq[2] = {
|
|||
[0] = {
|
||||
.handler = mb93493_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "mb93493.0",
|
||||
.dev_id = (void *) __addr_MB93493_IQSR(0),
|
||||
},
|
||||
[1] = {
|
||||
.handler = mb93493_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_SHARED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "mb93493.1",
|
||||
.dev_id = (void *) __addr_MB93493_IQSR(1),
|
||||
}
|
||||
|
|
|
@ -45,7 +45,6 @@ static irqreturn_t timer_interrupt(int irq, void *dummy);
|
|||
static struct irqaction timer_irq = {
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_DISABLED,
|
||||
.mask = CPU_MASK_NONE,
|
||||
.name = "timer",
|
||||
};
|
||||
|
||||
|
|
|
@ -60,7 +60,6 @@ static struct irqaction itu_irq = {
|
|||
.name = "itu",
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_TIMER,
|
||||
.mask = CPU_MASK_NONE,
|
||||
};
|
||||
|
||||
static const int __initdata divide_rate[] = {1, 2, 4, 8};
|
||||
|
|
|
@ -55,7 +55,6 @@ static struct irqaction timer16_irq = {
|
|||
.name = "timer-16",
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_TIMER,
|
||||
.mask = CPU_MASK_NONE,
|
||||
};
|
||||
|
||||
static const int __initdata divide_rate[] = {1, 2, 4, 8};
|
||||
|
|
|
@ -75,7 +75,6 @@ static struct irqaction timer8_irq = {
|
|||
.name = "timer-8",
|
||||
.handler = timer_interrupt,
|
||||
.flags = IRQF_DISABLED | IRQF_TIMER,
|
||||
.mask = CPU_MASK_NONE,
|
||||
};
|
||||
|
||||
static const int __initdata divide_rate[] = {8, 64, 8192};
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue