提交 1ff8392c 编写于 作者: S Steve French

Merge branch 'master' of /pub/scm/linux/kernel/git/torvalds/linux-2.6

Conflicts:

	fs/cifs/export.c

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
......@@ -45,3 +45,6 @@ series
# cscope files
cscope.*
*.orig
*.rej
......@@ -12,6 +12,8 @@ Following translations are available on the WWW:
00-INDEX
- this file.
ABI/
- info on kernel <-> userspace ABI and relative interface stability.
BUG-HUNTING
- brute force method of doing binary search of patches to find bug.
Changes
......@@ -25,37 +27,57 @@ DMA-mapping.txt
DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
- The process and procedures of how to do Linux kernel development.
- the process and procedures of how to do Linux kernel development.
IO-mapping.txt
- how to access I/O mapped memory from within device drivers.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ.txt
- description of what an IRQ is.
ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
README.cycladesZ
- info on Cyclades-Z firmware loading.
SAK.txt
- info on Secure Attention Keys.
SecurityBugs
- procedure for reporting security bugs found in the kernel.
SubmitChecklist
- Linux kernel patch submission checklist.
SubmittingDrivers
- procedure to get a new driver source included into the kernel tree.
SubmittingPatches
- procedure to get a source patch included into the kernel tree.
VGA-softcursor.txt
- how to change your VGA cursor from a blinking underscore.
accounting/
- documentation on accounting and taskstats.
aoe/
- description of AoE (ATA over Ethernet) along with config examples.
applying-patches.txt
- description of various trees and how to apply their patches.
arm/
- directory with info about Linux on the ARM architecture.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
- misc. LCD driver documentation (cfag12864b, ks0108).
basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
binfmt_misc.txt
- info on the kernel support for extra binary formats.
blackfin/
- directory with documentation for the Blackfin arch.
block/
- info on the Block I/O (BIO) layer.
cachetlb.txt
......@@ -68,16 +90,32 @@ cli-sti-removal.txt
- cli()/sti() removal guide.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
- documentation on Linux console drivers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
cpu-freq/
- info on CPU frequency and voltage scaling.
cpu-hotplug.txt
- document describing CPU hotplug support in the Linux kernel.
cpu-load.txt
- document describing how CPU load statistics are collected.
cpusets.txt
- documents the cpusets feature; assign CPUs and Mem to a set of tasks.
cputopology.txt
- documentation on how CPU topology info is exported via sysfs.
cris/
- directory with info about Linux on CRIS architecture.
crypto/
- directory with info on the Crypto API.
dcdbas.txt
- information on the Dell Systems Management Base Driver.
debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
dell_rbu.txt
- document demonstrating the use of the Dell Remote BIOS Update driver.
device-mapper/
- directory with info on Device Mapper.
devices.txt
......@@ -86,32 +124,52 @@ digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
dnotify.txt
- info about directory notification in Linux.
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
- directory with info about Linux driver model.
drivers/
- directory with driver documentation (currently only EDAC).
dvb/
- info on Linux Digital Video Broadcast (DVB) subsystem.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
ecryptfs.txt
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
eisa.txt
- info on EISA bus support.
exception.txt
- how Linux v2.2 handles exceptions without verify_area etc.
fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
- directory with info on the frame buffer graphics abstraction layer.
feature-removal-schedule.txt
- list of files and features that are going to be removed.
filesystems/
- directory with info on the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
floppy.txt
- notes and driver options for the floppy disk driver.
fujitsu/
- Fujitsu FR-V Linux documentation.
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hpet.txt
- High Precision Event Timer Driver for Linux.
hrtimer/
- info on the timer_stats debugging facility for timer (ab)use.
hrtimers/
- info on the hrtimers subsystem for high-resolution kernel timers.
hw_random.txt
- info on Linux support for random number generator in i8xx chipsets.
hwmon/
- directory with docs on various hardware monitoring drivers.
i2c/
- directory with info about the I2C bus/protocol (2 wire, kHz speed).
i2o/
......@@ -122,16 +180,22 @@ ia64/
- directory with info about Linux on Intel 64 bit architecture.
ide.txt
- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
infiniband/
- directory with documents concerning Linux InfiniBand support.
initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/
- directory with documents describing various IOCTL calls.
ioctl-number.txt
- how to implement and register device/driver ioctl calls.
iostats.txt
- info on I/O statistics Linux kernel provides.
irqflags-tracing.txt
- how to use the irq-flags tracing feature.
isapnp.txt
- info on Linux ISA Plug & Play support.
isdn/
......@@ -140,26 +204,40 @@ java.txt
- info on the in-kernel binary support for Java(tm).
kbuild/
- directory with info about the kernel build process.
kdumpt.txt
- mini HowTo on getting the crash dump code to work.
kdump/
- directory with mini HowTo on getting the crash dump code to work.
kernel-doc-nano-HOWTO.txt
- mini HowTo on generation and location of kernel documentation files.
kernel-docs.txt
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
keys-request-key.txt
- description of the kernel key request service.
keys.txt
- description of the kernel key retention service.
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
- documents the kernel probes debugging feature.
kref.txt
- docs on adding reference counters (krefs) to kernel objects.
laptop-mode.txt
- How to conserve battery power using laptop-mode.
- how to conserve battery power using laptop-mode.
ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
leds-class.txt
- documents LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
locks.txt
- info on file locking implementations, flock() vs. fcntl(), etc.
logo.gif
- Full colour GIF image of Linux logo (penguin).
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- Info on creator of above logo & site to get additional images from.
- info on creator of above logo & site to get additional images from.
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
......@@ -170,6 +248,8 @@ mca.txt
- info on supporting Micro Channel Architecture (e.g. PS/2) systems.
md.txt
- info on boot arguments for the multiple devices driver.
memory-barriers.txt
- info on Linux kernel memory barriers.
memory.txt
- info on typical Linux memory problems.
mips/
......@@ -177,9 +257,11 @@ mips/
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
moxa-smartio
- info on installing/using Moxa multiport serial driver.
- file with info on installing/using Moxa multiport serial driver.
mtrr.txt
- how to use PPro Memory Type Range Registers to increase performance.
mutex-design.txt
- info on the generic mutex subsystem.
nbd.txt
- info on a TCP implementation of a network block device.
netlabel/
......@@ -190,6 +272,8 @@ nfsroot.txt
- short guide on setting up a diskless box with NFS root filesystem.
nmi_watchdog.txt
- info on NMI watchdog for SMP systems.
nommu-mmap.txt
- documentation about no-mmu memory mapping support.
numastat.txt
- info on how to read Numa policy hit/miss statistics in sysfs.
oops-tracing.txt
......@@ -202,8 +286,16 @@ parport.txt
- how to use the parallel-port driver.
parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pci-error-recovery.txt
- info on PCI error recovery.
pci.txt
- info on the PCI subsystem for device driver authors.
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO.
pcmcia/
- info on the Linux PCMCIA driver.
pi-futex.txt
- documentation on lightweight PI-futexes.
pm.txt
- info on Linux power management support.
pnp.txt
......@@ -214,18 +306,32 @@ powerpc/
- directory with info on using Linux with the PowerPC.
preempt-locking.txt
- info on locking under a preemptive kernel.
prio_tree.txt
- info on radix-priority-search-tree use for indexing vmas.
ramdisk.txt
- short guide on how to set up and use the RAM disk.
rbtree.txt
- info on what red-black trees are and what they are for.
riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer.
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
- desc. of RT-mutex subsystem with PI (Priority Inheritance) support.
rtc.txt
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
s390/
- directory with info on using Linux on the IBM S390.
sched-arch.txt
- CPU Scheduler implementation hints for architecture specific code.
sched-coding.txt
- reference for various scheduler-related methods in the O(1) scheduler.
sched-design.txt
......@@ -240,22 +346,32 @@ serial/
- directory with info on the low level serial API.
serial-console.txt
- how to set up Linux with a serial line console as the default.
sgi-ioc4.txt
- description of the SGI IOC4 PCI (multi function) device.
sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
sharedsubtree.txt
- a description of shared subtrees for namespaces.
smart-config.txt
- description of the Smart Config makefile feature.
smp.txt
- a few notes on symmetric multi-processing.
sony-laptop.txt
- Sony Notebook Control Driver (SNC) Readme.
sonypi.txt
- info on Linux Sony Programmable I/O Device support.
sound/
- directory with info on sound card support.
sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
spinlocks.txt
- info on using spinlocks to provide exclusive access in kernel.
stable_api_nonsense.txt
......@@ -274,24 +390,32 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
thinkpad-acpi.txt
- information on the (IBM and Lenovo) ThinkPad ACPI Extras driver.
time_interpolators.txt
- info on time interpolators.
tipar.txt
- information about Parallel link cable for Texas Instruments handhelds.
tty.txt
- guide to the locking policies of the tty layer.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
uml/
- directory with information about User Mode Linux.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt
- description of the Linux unshare system call.
usb/
- directory with info regarding the Universal Serial Bus.
video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
vm/
- directory with info on the Linux vm code.
voyager.txt
- guide to running Linux on the Voyager architecture.
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
x86_64/
......
What: legacy isochronous ABI of raw1394 (1st generation iso ABI)
Date: June 2007 (scheduled), removed in kernel v2.6.23
Contact: linux1394-devel@lists.sourceforge.net
Description:
The two request types RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN have
been deprecated for quite some time. They are very inefficient as they
come with high interrupt load and several layers of callbacks for each
packet. Because of these deficiencies, the video1394 and dv1394 drivers
and the 3rd-generation isochronous ABI in raw1394 (rawiso) were created.
Users:
libraw1394 users via the long deprecated API raw1394_iso_write,
raw1394_start_iso_write, raw1394_start_iso_rcv, raw1394_stop_iso_rcv
libdc1394, which optionally uses these old libraw1394 calls
alternatively to the more efficient video1394 ABI
......@@ -39,3 +39,16 @@ Description:
If you want to suspend a device immediately but leave it
free to wake up in response to I/O requests, you should
write "0" to power/autosuspend.
What: /sys/bus/usb/devices/.../power/persist
Date: May 2007
KernelVersion: 2.6.23
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
If CONFIG_USB_PERSIST is set, then each USB device directory
will contain a file named power/persist. The file holds a
boolean value (0 or 1) indicating whether or not the
"USB-Persist" facility is enabled for the device. Since the
facility is inherently dangerous, it is disabled by default
for all devices except hubs. For more information, see
Documentation/usb/persist.txt.
......@@ -218,6 +218,18 @@ no space after the prefix increment & decrement unary operators:
and no space around the '.' and "->" structure member operators.
Do not leave trailing whitespace at the ends of lines. Some editors with
"smart" indentation will insert whitespace at the beginning of new lines as
appropriate, so you can start typing the next line of code right away.
However, some such editors do not remove the whitespace if you end up not
putting a line of code there, such as if you leave a blank line. As a result,
you end up with lines containing trailing whitespace.
Git will warn you about patches that introduce trailing whitespace, and can
optionally strip the trailing whitespace for you; however, if applying a series
of patches, this may make later patches in the series fail by changing their
context lines.
Chapter 4: Naming
......@@ -726,6 +738,33 @@ need them. Feel free to peruse that header file to see what else is already
defined that you shouldn't reproduce in your code.
Chapter 18: Editor modelines and other cruft
Some editors can interpret configuration information embedded in source files,
indicated with special markers. For example, emacs interprets lines marked
like this:
-*- mode: c -*-
Or like this:
/*
Local Variables:
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
End:
*/
Vim interprets markers that look like this:
/* vim:set sw=8 noet */
Do not include any of these in source files. People have their own personal
editor configurations, and your source files should not override them. This
includes markers for indentation and mode configuration. People may use their
own custom mode, or may have some other magic method for making indentation
work correctly.
Appendix I: References
......
......@@ -664,109 +664,6 @@ It is that simple.
Well, not for some odd devices. See the next section for information
about that.
DAC Addressing for Address Space Hungry Devices
There exists a class of devices which do not mesh well with the PCI
DMA mapping API. By definition these "mappings" are a finite
resource. The number of total available mappings per bus is platform
specific, but there will always be a reasonable amount.
What is "reasonable"? Reasonable means that networking and block I/O
devices need not worry about using too many mappings.
As an example of a problematic device, consider compute cluster cards.
They can potentially need to access gigabytes of memory at once via
DMA. Dynamic mappings are unsuitable for this kind of access pattern.
To this end we've provided a small API by which a device driver
may use DAC cycles to directly address all of physical memory.
Not all platforms support this, but most do. It is easy to determine
whether the platform will work properly at probe time.
First, understand that there may be a SEVERE performance penalty for
using these interfaces on some platforms. Therefore, you MUST only
use these interfaces if it is absolutely required. %99 of devices can
use the normal APIs without any problems.
Note that for streaming type mappings you must either use these
interfaces, or the dynamic mapping interfaces above. You may not mix
usage of both for the same device. Such an act is illegal and is
guaranteed to put a banana in your tailpipe.
However, consistent mappings may in fact be used in conjunction with
these interfaces. Remember that, as defined, consistent mappings are
always going to be SAC addressable.
The first thing your driver needs to do is query the PCI platform
layer if it is capable of handling your devices DAC addressing
capabilities:
int pci_dac_dma_supported(struct pci_dev *hwdev, u64 mask);
You may not use the following interfaces if this routine fails.
Next, DMA addresses using this API are kept track of using the
dma64_addr_t type. It is guaranteed to be big enough to hold any
DAC address the platform layer will give to you from the following
routines. If you have consistent mappings as well, you still
use plain dma_addr_t to keep track of those.
All mappings obtained here will be direct. The mappings are not
translated, and this is the purpose of this dialect of the DMA API.
All routines work with page/offset pairs. This is the _ONLY_ way to
portably refer to any piece of memory. If you have a cpu pointer
(which may be validly DMA'd too) you may easily obtain the page
and offset using something like this:
struct page *page = virt_to_page(ptr);
unsigned long offset = offset_in_page(ptr);
Here are the interfaces:
dma64_addr_t pci_dac_page_to_dma(struct pci_dev *pdev,
struct page *page,
unsigned long offset,
int direction);
The DAC address for the tuple PAGE/OFFSET are returned. The direction
argument is the same as for pci_{map,unmap}_single(). The same rules
for cpu/device access apply here as for the streaming mapping
interfaces. To reiterate:
The cpu may touch the buffer before pci_dac_page_to_dma.
The device may touch the buffer after pci_dac_page_to_dma
is made, but the cpu may NOT.
When the DMA transfer is complete, invoke:
void pci_dac_dma_sync_single_for_cpu(struct pci_dev *pdev,
dma64_addr_t dma_addr,
size_t len, int direction);
This must be done before the CPU looks at the buffer again.
This interface behaves identically to pci_dma_sync_{single,sg}_for_cpu().
And likewise, if you wish to let the device get back at the buffer after
the cpu has read/written it, invoke:
void pci_dac_dma_sync_single_for_device(struct pci_dev *pdev,
dma64_addr_t dma_addr,
size_t len, int direction);
before letting the device access the DMA area again.
If you need to get back to the PAGE/OFFSET tuple from a dma64_addr_t
the following interfaces are provided:
struct page *pci_dac_dma_to_page(struct pci_dev *pdev,
dma64_addr_t dma_addr);
unsigned long pci_dac_dma_to_offset(struct pci_dev *pdev,
dma64_addr_t dma_addr);
This is possible with the DAC interfaces purely because they are
not translated in any way.
Optimizing Unmap State Space Consumption
On many platforms, pci_unmap_{single,page}() is simply a nop.
......
......@@ -139,8 +139,10 @@ X!Ilib/string.c
!Elib/cmdline.c
</sect1>
<sect1><title>CRC Functions</title>
<sect1 id="crc"><title>CRC Functions</title>
!Elib/crc7.c
!Elib/crc16.c
!Elib/crc-itu-t.c
!Elib/crc32.c
!Elib/crc-ccitt.c
</sect1>
......@@ -643,4 +645,70 @@ X!Idrivers/video/console/fonts.c
!Edrivers/spi/spi.c
</chapter>
<chapter id="i2c">
<title>I<superscript>2</superscript>C and SMBus Subsystem</title>
<para>
I<superscript>2</superscript>C (or without fancy typography, "I2C")
is an acronym for the "Inter-IC" bus, a simple bus protocol which is
widely used where low data rate communications suffice.
Since it's also a licensed trademark, some vendors use another
name (such as "Two-Wire Interface", TWI) for the same bus.
I2C only needs two signals (SCL for clock, SDA for data), conserving
board real estate and minimizing signal quality issues.
Most I2C devices use seven bit addresses, and bus speeds of up
to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
found wide use.
I2C is a multi-master bus; open drain signaling is used to
arbitrate between masters, as well as to handshake and to
synchronize clocks from slower clients.
</para>
<para>
The Linux I2C programming interfaces support only the master
side of bus interactions, not the slave side.
The programming interface is structured around two kinds of driver,
and two kinds of device.
An I2C "Adapter Driver" abstracts the controller hardware; it binds
to a physical device (perhaps a PCI device or platform_device) and
exposes a <structname>struct i2c_adapter</structname> representing
each I2C bus segment it manages.
On each I2C bus segment will be I2C devices represented by a
<structname>struct i2c_client</structname>. Those devices will
be bound to a <structname>struct i2c_driver</structname>,
which should follow the standard Linux driver model.
(At this writing, a legacy model is more widely used.)
There are functions to perform various I2C protocol operations; at
this writing all such functions are usable only from task context.
</para>
<para>
The System Management Bus (SMBus) is a sibling protocol. Most SMBus
systems are also I2C conformant. The electrical constraints are
tighter for SMBus, and it standardizes particular protocol messages
and idioms. Controllers that support I2C can also support most
SMBus operations, but SMBus controllers don't support all the protocol
options that an I2C controller will.
There are functions to perform various SMBus protocol operations,
either using I2C primitives or by issuing SMBus commands to
i2c_adapter devices which don't support those I2C operations.
</para>
!Iinclude/linux/i2c.h
!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="splice">
<title>splice API</title>
<para>)
splice is a method for moving blocks of data around inside the
kernel, without continually transferring it between the kernel
and user space.
</para>
!Iinclude/linux/splice.h
!Ffs/splice.c
</chapter>
</book>
......@@ -352,49 +352,93 @@ entry->write_proc = write_proc_foo;
<funcsynopsis>
<funcprototype>
<funcdef>int <function>read_func</function></funcdef>
<paramdef>char* <parameter>page</parameter></paramdef>
<paramdef>char* <parameter>buffer</parameter></paramdef>
<paramdef>char** <parameter>start</parameter></paramdef>
<paramdef>off_t <parameter>off</parameter></paramdef>
<paramdef>int <parameter>count</parameter></paramdef>
<paramdef>int* <parameter>eof</parameter></paramdef>
<paramdef>int* <parameter>peof</parameter></paramdef>
<paramdef>void* <parameter>data</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
The read function should write its information into the
<parameter>page</parameter>. For proper use, the function
should start writing at an offset of
<parameter>off</parameter> in <parameter>page</parameter> and
write at most <parameter>count</parameter> bytes, but because
most read functions are quite simple and only return a small
amount of information, these two parameters are usually
ignored (it breaks pagers like <literal>more</literal> and
<literal>less</literal>, but <literal>cat</literal> still
works).
<parameter>buffer</parameter>, which will be exactly
<literal>PAGE_SIZE</literal> bytes long.
</para>
<para>
If the <parameter>off</parameter> and
<parameter>count</parameter> parameters are properly used,
<parameter>eof</parameter> should be used to signal that the
The parameter
<parameter>peof</parameter> should be used to signal that the
end of the file has been reached by writing
<literal>1</literal> to the memory location
<parameter>eof</parameter> points to.
<parameter>peof</parameter> points to.
</para>
<para>
The parameter <parameter>start</parameter> doesn't seem to be
used anywhere in the kernel. The <parameter>data</parameter>
The <parameter>data</parameter>
parameter can be used to create a single call back function for
several files, see <xref linkend="usingdata"/>.
</para>
<para>
The <function>read_func</function> function must return the
number of bytes written into the <parameter>page</parameter>.
The rest of the parameters and the return value are described
by a comment in <filename>fs/proc/generic.c</filename> as follows:
</para>
<blockquote>
<para>
You have three ways to return data:
</para>
<orderedlist>
<listitem>
<para>
Leave <literal>*start = NULL</literal>. (This is the default.)
Put the data of the requested offset at that
offset within the buffer. Return the number (<literal>n</literal>)
of bytes there are from the beginning of the
buffer up to the last byte of data. If the
number of supplied bytes (<literal>= n - offset</literal>) is
greater than zero and you didn't signal eof
and the reader is prepared to take more data
you will be called again with the requested
offset advanced by the number of bytes
absorbed. This interface is useful for files
no larger than the buffer.
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> to an unsigned long value less than
the buffer address but greater than zero.
Put the data of the requested offset at the
beginning of the buffer. Return the number of
bytes of data placed there. If this number is
greater than zero and you didn't signal eof
and the reader is prepared to take more data
you will be called again with the requested
offset advanced by <literal>*start</literal>. This interface is
useful when you have a large file consisting
of a series of blocks which you want to count
and return as wholes.
(Hack by Paul.Russell@rustcorp.com.au)
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> to an address within the buffer.
Put the data of the requested offset at <literal>*start</literal>.
Return the number of bytes of data placed there.
If this number is greater than zero and you
didn't signal eof and the reader is prepared to
take more data you will be called again with the
requested offset advanced by the number of bytes
absorbed.
</para>
</listitem>
</orderedlist>
</blockquote>
<para>
<xref linkend="example"/> shows how to use a read call back
function.
......
......@@ -322,39 +322,34 @@ kernel releases as described above.
Here is a list of some of the different kernel trees available:
git trees:
- Kbuild development tree, Sam Ravnborg <sam@ravnborg.org>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI development tree, Len Brown <len.brown@intel.com>
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- Block development tree, Jens Axboe <axboe@suse.de>
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM development tree, Dave Airlie <airlied@linux.ie>
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 development tree, Tony Luck <tony.luck@intel.com>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394 development tree, Jody McIntyre <scjody@modernduck.com>
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- infiniband, Roland Dreier <rolandd@cisco.com>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- network drivers, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
Other git kernel trees can be found listed at http://kernel.org/git
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
......@@ -362,6 +357,9 @@ Here is a list of some of the different kernel trees available:
- x86-64, partly i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.
Bug Reporting
-------------
......
......@@ -222,7 +222,15 @@ over a rather long period of time, but improvements are always welcome!
deadlock as soon as the RCU callback happens to interrupt that
acquisition's critical section.
13. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
13. RCU callbacks can be and are executed in parallel. In many cases,
the callback code simply wrappers around kfree(), so that this
is not an issue (or, more accurately, to the extent that it is
an issue, the memory-allocator locking handles it). However,
if the callbacks do manipulate a shared data structure, they
must use whatever locking or other synchronization is required
to safely access and/or modify that data structure.
14. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
may only be invoked from process context. Unlike other forms of
RCU, it -is- permissible to block in an SRCU read-side critical
section (demarked by srcu_read_lock() and srcu_read_unlock()),
......
SM501 Driver
============
Copyright 2006, 2007 Simtec Electronics
Core
----
The core driver in drivers/mfd provides common services for the
drivers which manage the specific hardware blocks. These services
include locking for common registers, clock control and resource
management.
The core registers drivers for both PCI and generic bus based
chips via the platform device and driver system.
On detection of a device, the core initialises the chip (which may
be specified by the platform data) and then exports the selected
peripheral set as platform devices for the specific drivers.
The core re-uses the platform device system as the platform device
system provides enough features to support the drivers without the
need to create a new bus-type and the associated code to go with it.
Resources
---------
Each peripheral has a view of the device which is implicitly narrowed to
the specific set of resources that peripheral requires in order to
function correctly.
The centralised memory allocation allows the driver to ensure that the
maximum possible resource allocation can be made to the video subsystem
as this is by-far the most resource-sensitive of the on-chip functions.
The primary issue with memory allocation is that of moving the video
buffers once a display mode is chosen. Indeed when a video mode change
occurs the memory footprint of the video subsystem changes.
Since video memory is difficult to move without changing the display
(unless sufficient contiguous memory can be provided for the old and new
modes simultaneously) the video driver fully utilises the memory area
given to it by aligning fb0 to the start of the area and fb1 to the end
of it. Any memory left over in the middle is used for the acceleration
functions, which are transient and thus their location is less critical
as it can be moved.
Configuration
-------------
The platform device driver uses a set of platform data to pass
configurations through to the core and the subsidiary drivers
so that there can be support for more than one system carrying
an SM501 built into a single kernel image.
The PCI driver assumes that the PCI card behaves as per the Silicon
Motion reference design.
There is an errata (AB-5) affecting the selection of the
of the M1XCLK and M1CLK frequencies. These two clocks
must be sourced from the same PLL, although they can then
be divided down individually. If this is not set, then SM501 may
lock and hang the whole system. The driver will refuse to
attach if the PLL selection is different.
Linux Kernel patch sumbittal checklist
Linux Kernel patch submission checklist
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here are some basic things that developers should do if they want to see their
......@@ -9,7 +9,6 @@ Documentation/SubmittingPatches and elsewhere regarding submitting Linux
kernel patches.
1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
=n. No gcc warnings/errors, no linker warnings/errors.
......
......@@ -464,9 +464,25 @@ section Linus Computer Science 101.
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
Once significant exception is when moving code from one file to
another in this case you should not modify the moved code at all in
the same patch which moves it. This clearly delineates the act of
moving the code and your changes. This greatly aids review of the
actual differences and allows tools to better track the history of
the code itself.
Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl). You should be able to justify all
violations that remain in your patch.
(scripts/checkpatch.pl). The style checker should be viewed as
a guide not as the final word. If your code looks better with
a violation then its probably best left alone.
The checker reports at three levels:
- ERROR: things that are very likely to be wrong
- WARNING: things requiring careful review
- CHECK: things requiring thought
You should be able to justify all violations that remain in your
patch.
......
......@@ -49,6 +49,7 @@ char name[100];
int dbg;
int print_delays;
int print_io_accounting;
int print_task_context_switch_counts;
__u64 stime, utime;
#define PRINTF(fmt, arg...) { \
......@@ -195,7 +196,7 @@ void print_delayacct(struct taskstats *t)
"IO %15s%15s\n"
" %15llu%15llu\n"
"MEM %15s%15s\n"
" %15llu%15llu\n\n",
" %15llu%15llu\n"
"count", "real total", "virtual total", "delay total",
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
t->cpu_delay_total,
......@@ -204,6 +205,14 @@ void print_delayacct(struct taskstats *t)
"count", "delay total", t->swapin_count, t->swapin_delay_total);
}
void task_context_switch_counts(struct taskstats *t)
{
printf("\n\nTask %15s%15s\n"
" %15lu%15lu\n",
"voluntary", "nonvoluntary",
t->nvcsw, t->nivcsw);
}
void print_ioacct(struct taskstats *t)
{
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
......@@ -235,7 +244,7 @@ int main(int argc, char *argv[])
struct msgtemplate msg;
while (1) {
c = getopt(argc, argv, "diw:r:m:t:p:vl");
c = getopt(argc, argv, "qdiw:r:m:t:p:vl");
if (c < 0)
break;
......@@ -248,6 +257,10 @@ int main(int argc, char *argv[])
printf("printing IO accounting\n");
print_io_accounting = 1;
break;
case 'q':
printf("printing task/process context switch rates\n");
print_task_context_switch_counts = 1;
break;
case 'w':
logfile = strdup(optarg);
printf("write to file %s\n", logfile);
......@@ -389,6 +402,8 @@ int main(int argc, char *argv[])
print_delayacct((struct taskstats *) NLA_DATA(na));
if (print_io_accounting)
print_ioacct((struct taskstats *) NLA_DATA(na));
if (print_task_context_switch_counts)
task_context_switch_counts((struct taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
err(1,"write error\n");
......
......@@ -22,6 +22,8 @@ There are three different groups of fields in the struct taskstats:
/* Extended accounting fields end */
Their values are collected if CONFIG_TASK_XACCT is set.
4) Per-task and per-thread context switch count statistics
Future extension should add fields to the end of the taskstats struct, and
should not change the relative position of each field within the struct.
......@@ -158,4 +160,8 @@ struct taskstats {
/* Extended accounting fields end */
4) Per-task and per-thread statistics
__u64 nvcsw; /* Context voluntary switch counter */
__u64 nivcsw; /* Context involuntary switch counter */
}
A Simple Guide to Configure KGDB
Sonic Zhang <sonic.zhang@analog.com>
Aug. 24th 2006
This KGDB patch enables the kernel developer to do source level debugging on
the kernel for the Blackfin architecture. The debugging works over either the
ethernet interface or one of the uarts. Both software breakpoints and
hardware breakpoints are supported in this version.
http://docs.blackfin.uclinux.org/doku.php?id=kgdb
2 known issues:
1. This bug:
http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=544&group_id=18&atid=145
The GDB client for Blackfin uClinux causes incorrect values of local
variables to be displayed when the user breaks the running of kernel in GDB.
2. Because of a hardware bug in Blackfin 533 v1.0.3:
05000067 - Watchpoints (Hardware Breakpoints) are not supported
Hardware breakpoints cannot be set properly.
Debug over Ethernet:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over (Ethernet)". Add "kgdboe=@target-IP/,@host-IP/" to
the option "Compiled-in Kernel Boot Parameter" under "Kernel hacking".
4. Connect minicom to the serial port and boot the kernel image.
5. Configure the IP "/> ifconfig eth0 target-IP"
6. Start GDB client "bfin-elf-gdb vmlinux".
7. Connect to the target "(gdb) target remote udp:target-IP:6443".
8. Set software breakpoint "(gdb) break sys_open".
9. Continue "(gdb) c".
10. Run ls in the target console "/> ls".
11. Breakpoint hits. "Breakpoint 1: sys_open(..."
12. Display local variables and function paramters.
(*) This operation gives wrong results, see known issue 1.
13. Single stepping "(gdb) si".
14. Remove breakpoint 1. "(gdb) del 1"
15. Set hardware breakpoint "(gdb) hbreak sys_open".
16. Continue "(gdb) c".
17. Run ls in the target console "/> ls".
18. Hardware breakpoint hits. "Breakpoint 1: sys_open(...".
(*) This hardware breakpoint will not be hit, see known issue 2.
19. Continue "(gdb) c".
20. Interrupt the target in GDB "Ctrl+C".
21. Detach from the target "(gdb) detach".
22. Exit GDB "(gdb) quit".
Debug over the UART:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over (UART)". Set "KGDB: UART port number" to be
a different one from the console. Don't forget to change the mode of
blackfin serial driver to PIO. Otherwise kgdb works incorrectly on UART.
4. If you want connect to kgdb when the kernel boots, enable
"KGDB: Wait for gdb connection early"
5. Compile kernel.
6. Connect minicom to the serial port of the console and boot the kernel image.
7. Start GDB client "bfin-elf-gdb vmlinux".
8. Set the baud rate in GDB "(gdb) set remotebaud 57600".
9. Connect to the target on the second serial port "(gdb) target remote /dev/ttyS1".
10. Set software breakpoint "(gdb) break sys_open".
11. Continue "(gdb) c".
12. Run ls in the target console "/> ls".
13. A breakpoint is hit. "Breakpoint 1: sys_open(..."
14. All other operations are the same as that in KGDB over Ethernet.
Debug over the same UART as console:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over UART". Set "KGDB: UART port number" to console.
Don't forget to change the mode of blackfin serial driver to PIO.
Otherwise kgdb works incorrectly on UART.
4. If you want connect to kgdb when the kernel boots, enable
"KGDB: Wait for gdb connection early"
5. Connect minicom to the serial port and boot the kernel image.
6. (Optional) Ask target to wait for gdb connection by entering Ctrl+A. In minicom, you should enter Ctrl+A+A.
7. Start GDB client "bfin-elf-gdb vmlinux".
8. Set the baud rate in GDB "(gdb) set remotebaud 57600".
9. Connect to the target "(gdb) target remote /dev/ttyS0".
10. Set software breakpoint "(gdb) break sys_open".
11. Continue "(gdb) c". Then enter Ctrl+C twice to stop GDB connection.
12. Run ls in the target console "/> ls". Dummy string can be seen on the console.
13. Then connect the gdb to target again. "(gdb) target remote /dev/ttyS0".
Now you will find a breakpoint is hit. "Breakpoint 1: sys_open(..."
14. All other operations are the same as that in KGDB over Ethernet. The only
difference is that after continue command in GDB, please stop GDB
connection by 2 "Ctrl+C"s and connect again after breakpoints are hit or
Ctrl+A is entered.
......@@ -82,23 +82,12 @@ including draining and flushing.
typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq);
int blk_queue_ordered(request_queue_t *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn,
unsigned gfp_mask);
int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn,
unsigned gfp_mask);
The only difference between the two functions is whether or not the
caller is holding q->queue_lock on entry. The latter expects the
caller is holding the lock.
prepare_flush_fn *prepare_flush_fn);
@q : the queue in question
@ordered : the ordered mode the driver/device supports
@prepare_flush_fn : this function should prepare @rq such that it
flushes cache to physical medium when executed
@gfp_mask : gfp_mask used when allocating data structures
for ordered processing
For example, SCSI disk driver's prepare_flush_fn looks like the
following.
......@@ -106,9 +95,10 @@ following.
static void sd_prepare_flush(request_queue_t *q, struct request *rq)
{
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->flags |= REQ_BLOCK_PC;
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->timeout = SD_TIMEOUT;
rq->cmd[0] = SYNCHRONIZE_CACHE;
rq->cmd_len = 10;
}
The following seven ordered modes are supported. The following table
......
......@@ -253,7 +253,7 @@ Here are the routines, one by one:
The first of these two routines is invoked after map_vm_area()
has installed the page table entries. The second is invoked
before unmap_vm_area() deletes the page table entries.
before unmap_kernel_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.
......
......@@ -2,32 +2,10 @@
- this file (info on CD-ROMs and Linux)
Makefile
- only used to generate TeX output from the documentation.
aztcd
- info on Aztech/Orchid/Okano/Wearnes/Conrad/CyCDROM driver.
cdrom-standard.tex
- LaTeX document on standardizing the CD-ROM programming interface.
cdu31a
- info on the Sony CDU31A/CDU33A CD-ROM driver.
cm206
- info on the Philips/LMS cm206/cm260 CD-ROM driver.
gscd
- info on the Goldstar R420 CD-ROM driver.
ide-cd
- info on setting up and using ATAPI (aka IDE) CD-ROMs.
isp16
- info on the CD-ROM interface on ISP16, MAD16 or Mozart sound card.
mcd
- info on limitations of standard Mitsumi CD-ROM driver.
mcdx
- info on improved Mitsumi CD-ROM driver.
optcd
- info on the Optics Storage 8000 AT CD-ROM driver
packet-writing.txt
- Info on the CDRW packet writing module
sbpcd
- info on the SoundBlaster/Panasonic CD-ROM interface driver.
sjcd
- info on the SANYO CDR-H94A CD-ROM interface driver.
sonycd535
- info on the Sony CDU-535 (and 531) CD-ROM driver.
此差异已折叠。
CDU31A/CDU33A Driver Info
-------------------------
Information on the Sony CDU31A/CDU33A CDROM driver for the Linux
kernel.
Corey Minyard (minyard@metronet.com)
Colossians 3:17
Crude Table of Contents
-----------------------
Setting Up the Hardware
Configuring the Kernel
Configuring as a Module
Driver Special Features
This device driver handles Sony CDU31A/CDU33A CDROM drives and
provides a complete block-level interface as well as an ioctl()
interface as specified in include/linux/cdrom.h). With this
interface, CDROMs can be accessed, standard audio CDs can be played
back normally, and CD audio information can be read off the drive.
Note that this will only work for CDU31A/CDU33A drives. Some vendors
market their drives as CDU31A compatible. They lie. Their drives are
really CDU31A hardware interface compatible (they can plug into the
same card). They are not software compatible.
Setting Up the Hardware
-----------------------
The CDU31A driver is unable to safely tell if an interface card is
present that it can use because the interface card does not announce
its presence in any way besides placing 4 I/O locations in memory. It
used to just probe memory and attempt commands, but Linus wisely asked
me to remove that because it could really screw up other hardware in
the system.
Because of this, you must tell the kernel where the drive interface
is, what interrupts are used, and possibly if you are on a PAS-16
soundcard.
If you have the Sony CDU31A/CDU33A drive interface card, the following
diagram will help you set it up. If you have another card, you are on
your own. You need to make sure that the I/O address and interrupt is
not used by another card in the system. You will need to know the I/O
address and interrupt you have set. Note that use of interrupts is
highly recommended, if possible, it really cuts down on CPU used.
Unfortunately, most soundcards do not support interrupts for their
CDROM interfaces. By default, the Sony interface card comes with
interrupts disabled.
+----------+-----------------+----------------------+
| JP1 | 34 Pin Conn | |
| JP2 +-----------------+ |
| JP3 |
| JP4 |
| +--+
| | +-+
| | | | External
| | | | Connector
| | | |
| | +-+
| +--+
| |
| +--------+
| |
+------------------------------------------+
JP1 sets the Base Address, using the following settings:
Address Pin 1 Pin 2
------- ----- -----
0x320 Short Short
0x330 Short Open
0x340 Open Short
0x360 Open Open
JP2 and JP3 configure the DMA channel; they must be set the same.
DMA Pin 1 Pin 2 Pin 3
--- ----- ----- -----
1 On Off On
2 Off On Off
3 Off Off On
JP4 Configures the IRQ:
IRQ Pin 1 Pin 2 Pin 3 Pin 4
--- ----- ----- ----- -----
3 Off Off On Off
4 Off Off* Off On
5 On Off Off Off
6 Off On Off Off
The documentation states to set this for interrupt
4, but I think that is a mistake.
Note that if you have another interface card, you will need to look at
the documentation to find the I/O base address. This is specified to
the SLCD.SYS driver for DOS with the /B: parameter, so you can look at
you DOS driver setup to find the address, if necessary.
Configuring the Kernel
----------------------
You must tell the kernel where the drive is at boot time. This can be
done at the Linux boot prompt, by using LILO, or by using Bootlin.
Note that this is no substitute for HOWTOs and LILO documentation, if
you are confused please read those for info on bootline configuration
and LILO.
At the linux boot prompt, press the ALT key and add the following line
after the boot name (you can let the kernel boot, it will tell you the
default boot name while booting):
cdu31a=<base address>,<interrupt>[,PAS]
The base address needs to have "0x" in front of it, since it is in
hex. For instance, to configure a drive at address 320 on interrupt 5,
use the following:
cdu31a=0x320,5
I use the following boot line:
cdu31a=0x1f88,0,PAS
because I have a PAS-16 which does not support interrupt for the
CDU31A interface.
Adding this as an append line at the beginning of the /etc/lilo.conf
file will set it for lilo configurations. I have the following as the
first line in my lilo.conf file:
append="cdu31a=0x1f88,0"
I'm not sure how to set up Bootlin (I have never used it), if someone
would like to fill in this section please do.
Configuring as a Module
-----------------------
The driver supports loading as a module. However, you must specify
the boot address and interrupt on the boot line to insmod. You can't
use modprobe to load it, since modprobe doesn't support setting
variables.
Anyway, I use the following line to load my driver as a module
/sbin/insmod /lib/modules/`uname -r`/misc/cdu31a.o cdu31a_port=0x1f88
You can set the following variables in the driver:
cdu31a_port=<I/O address> - sets the base I/O. If hex, put 0x in
front of it. This must be specified.
cdu31a_irq=<interrupt> - Sets the interrupt number. Leaving this
off will turn interrupts off.
Driver Special Features
-----------------------
This section describes features beyond the normal audio and CD-ROM
functions of the drive.
2048 byte buffer mode
If a disk is mounted with -o block=2048, data is copied straight from
the drive data port to the buffer. Otherwise, the readahead buffer
must be involved to hold the other 1K of data when a 1K block
operation is done. Note that with 2048 byte blocks you cannot execute
files from the CD.
XA compatibility
The driver should support XA disks for both the CDU31A and CDU33A. It
does this transparently, the using program doesn't need to set it.
Multi-Session
A multi-session disk looks just like a normal disk to the user. Just
mount one normally, and all the data should be there. A special
thanks to Koen for help with this!
Raw sector I/O
Using the CDROMREADAUDIO it is possible to read raw audio and data
tracks. Both operations return 2352 bytes per sector. On the data
tracks, the first 12 bytes is not returned by the drive and the value
of that data is indeterminate.
This is the readme file for the driver for the Philips/LMS cdrom drive
cm206 in combination with the cm260 host adapter card.
(c) 1995 David A. van Leeuwen
Changes since version 0.99
--------------------------
- Interfacing to the kernel is routed though an extra interface layer,
cdrom.c. This allows runtime-configurable `behavior' of the cdrom-drive,
independent of the driver.
Features since version 0.33
---------------------------
- Full audio support, that is, both workman, workbone and cdp work
now reasonably. Reading TOC still takes some time. xmcd has been
reported to run successfully.
- Made auto-probe code a little better, I hope
Features since version 0.28
---------------------------
- Full speed transfer rate (300 kB/s).
- Minimum kernel memory usage for buffering (less than 3 kB).
- Multisession support.
- Tray locking.
- Statistics of driver accessible to the user.
- Module support.
- Auto-probing of adapter card's base port and irq line,
also configurable at boot time or module load time.
Decide how you are going to use the driver. There are two
options:
(a) installing the driver as a resident part of the kernel
(b) compiling the driver as a loadable module
Further, you must decide if you are going to specify the base port
address and the interrupt request line of the adapter card cm260 as
boot options for (a), module parameters for (b), use automatic
probing of these values, or hard-wire your adaptor card's settings
into the source code. If you don't care, you can choose
autoprobing, which is the default. In that case you can move on to
the next step.
Compiling the kernel
--------------------
1) move to /usr/src/linux and do a
make config
If you have chosen option (a), answer yes to CONFIG_CM206 and
CONFIG_ISO9660_FS.
If you have chosen option (b), answer yes to CONFIG_MODVERSIONS
and no (!) to CONFIG_CM206 and CONFIG_ISO9660_FS.
2) then do a
make clean; make zImage; make modules
3) do the usual things to install a new image (backup the old one, run
`rdev -R zImage 1', copy the new image in place, run lilo). Might
be `make zlilo'.
Using the driver as a module
----------------------------
If you will only occasionally use the cd-rom driver, you can choose
option (b), install as a loadable module. You may have to re-compile
the module when you upgrade the kernel to a new version.
Since version 0.96, much of the functionality has been transferred to
a generic cdrom interface in the file cdrom.c. The module cm206.o
depends on cdrom.o. If the latter is not compiled into the kernel,
you must explicitly load it before cm206.o:
insmod /usr/src/linux/modules/cdrom.o
To install the module, you use the command, as root
insmod /usr/src/linux/modules/cm206.o
You can specify the base address on the command line as well as the irq
line to be used, e.g.
insmod /usr/src/linux/modules/cm206.o cm206=0x300,11
The order of base port and irq line doesn't matter; if you specify only
one, the other will have the value of the compiled-in default. You
may also have to install the file-system module `iso9660.o', if you
didn't compile that into the kernel.
Using the driver as part of the kernel
--------------------------------------
If you have chosen option (a), you can specify the base-port
address and irq on the lilo boot command line, e.g.:
LILO: linux cm206=0x340,11
This assumes that your linux kernel image keyword is `linux'.
If you specify either IRQ (3--11) or base port (0x300--0x370),
auto probing is turned off for both settings, thus setting the
other value to the compiled-in default.
Note that you can also put these parameters in the lilo configuration file:
# linux config
image = /vmlinuz
root = /dev/hda1
label = Linux
append = "cm206=0x340,11"
read-only
If module parameters and LILO config options don't work
-------------------------------------------------------
If autoprobing does not work, you can hard-wire the default values
of the base port address (CM206_BASE) and interrupt request line
(CM206_IRQ) into the file /usr/src/linux/drivers/cdrom/cm206.h. Change
the defines of CM206_IRQ and CM206_BASE.
Mounting the cdrom
------------------
1) Make sure that the right device is installed in /dev.
mknod /dev/cm206cd b 32 0
2) Make sure there is a mount point, e.g., /cdrom
mkdir /cdrom
3) mount using a command like this (run as root):
mount -rt iso9660 /dev/cm206cd /cdrom
4) For user-mounts, add a line in /etc/fstab
/dev/cm206cd /cdrom iso9660 ro,noauto,user
This will allow users to give the commands
mount /cdrom
umount /cdrom
If things don't work
--------------------
- Try to do a `dmesg' to find out if the driver said anything about
what is going wrong during the initialization.
- Try to do a `dd if=/dev/cm206cd | od -tc | less' to read from the
CD.
- Look in the /proc directory to see if `cm206' shows up under one of
`interrupts', `ioports', `devices' or `modules' (if applicable).
DISCLAIMER
----------
I cannot guarantee that this driver works, or that the hardware will
not be harmed, although I consider it most unlikely.
I hope that you'll find this driver in some way useful.
David van Leeuwen
david@tm.tno.nl
Note for Linux CDROM vendors
-----------------------------
You are encouraged to include this driver on your Linux CDROM. If
you do, you might consider sending me a free copy of that cd-rom.
You can contact me through my e-mail address, david@tm.tno.nl.
If this driver is compiled into a kernel to boot off a cdrom,
you should actually send me a free copy of that cd-rom.
Copyright
---------
The copyright of the cm206 driver for Linux is
(c) 1995 David A. van Leeuwen
The driver is released under the conditions of the GNU general public
license, which can be found in the file COPYING in the root of this
source tree.
Goldstar R420 CD-Rom device driver README
For all kind of other information about the GoldStar R420 CDROM
and this Linux device driver see the WWW page:
http://linux.rz.fh-hannover.de/~raupach
If you are the editor of a Linux CD, you should
enable gscd.c within your boot floppy kernel. Please,
send me one of your CDs for free.
This current driver version 0.4a only supports reading data from the disk.
Currently we have no audio and no multisession or XA support.
The polling interface is used, no DMA.
Sometimes the GoldStar R420 is sold in a 'Reveal Multimedia Kit'. This kit's
drive interface is compatible, too.
Installation
------------
Change to '/usr/src/linux/drivers/cdrom' and edit the file 'gscd.h'. Insert
the i/o address of your interface card.
The default base address is 0x340. This will work for most applications.
Address selection is accomplished by jumpers PN801-1 to PN801-4 on the
GoldStar Interface Card.
Appropriate settings are: 0x300, 0x310, 0x320, 0x330, 0x340, 0x350, 0x360
0x370, 0x380, 0x390, 0x3A0, 0x3B0, 0x3C0, 0x3D0, 0x3E0, 0x3F0
Then go back to '/usr/src/linux/' and 'make config' to build the new
configuration for your kernel. If you want to use the GoldStar driver
like a module, don't select 'GoldStar CDROM support'. By the way, you
have to include the iso9660 filesystem.
Now start compiling the kernel with 'make zImage'.
If you want to use the driver as a module, you have to do 'make modules'
and 'make modules_install', additionally.
Install your new kernel as usual - maybe you do it with 'make zlilo'.
Before you can use the driver, you have to
mknod /dev/gscd0 b 16 0
to create the appropriate device file (you only need to do this once).
If you use modules, you can try to insert the driver.
Say: 'insmod /usr/src/linux/modules/gscd.o'
or: 'insmod /usr/src/linux/modules/gscd.o gscd=<address>'
The driver should report its results.
That's it! Mount a disk, i.e. 'mount -rt iso9660 /dev/gscd0 /cdrom'
Feel free to report errors and suggestions to the following address.
Be sure, I'm very happy to receive your comments!
Oliver Raupach Hannover, Juni 1995
(raupach@nwfs1.rz.fh-hannover.de)
-- Documentation/cdrom/isp16
Docs by Eric van der Maarel <H.T.M.v.d.Maarel@marin.nl>
This is the README for version 0.6 of the cdrom interface on an
ISP16, MAD16 or Mozart sound card.
The detection and configuration of this interface used to be included
in both the sjcd and optcd cdrom driver. Drives supported by these
drivers came packed with Media Magic's multi media kit, which also
included the ISP16 card. The idea (thanks Leo Spiekman)
to move it from these drivers into a separate module and moreover, not to
rely on the MAD16 sound driver, are as follows:
-duplication of code in the kernel is a waste of resources and should
be avoided;
-however, kernels and notably those included with Linux distributions
(cf Slackware 3.0 included version 0.5 of the isp16 configuration
code included in the drivers) don't always come with sound support
included. Especially when they already include a bunch of cdrom drivers.
Hence, the cdrom interface should be configurable _independently_ of
sound support.
The ISP16, MAD16 and Mozart sound cards have an OPTi 82C928 or an
OPTi 82C929 chip. The interface on these cards should work with
any cdrom attached to the card, which is 'electrically' compatible
with Sanyo/Panasonic, Sony or Mitsumi non-ide drives. However, the
command sets for any proprietary drives may differ
(and hence may not be supported in the kernel) from these four types.
For a fact I know the interface works and the way of configuration
as described in this documentation works in combination with the
sjcd (in Sanyo/Panasonic compatibility mode) cdrom drivers
(probably with the optcd (in Sony compatibility mode) as well).
If you have such an OPTi based sound card and you want to use the
cdrom interface with a cdrom drive supported by any of the other cdrom
drivers, it will probably work. Please let me know any experience you
might have).
I understand that cards based on the OPTi 82C929 chips may be configured
(hardware jumpers that is) as an IDE interface. Initialisation of such a
card in this mode is not supported (yet?).
The suggestion to configure the ISP16 etc. sound card by booting DOS and
do a warm reboot to boot Linux somehow doesn't work, at least not
on my machine (IPC P90), with the OPTi 82C928 based card.
Booting the kernel through the boot manager LILO allows the use
of some command line options on the 'LILO boot:' prompt. At boot time
press Alt or Shift while the LILO prompt is written on the screen and enter
any kernel options. Alternatively these options may be used in
the appropriate section in /etc/lilo.conf. Adding 'append="<cmd_line_options>"'
will do the trick as well.
The syntax of 'cmd_line_options' is
isp16=[<port>[,<irq>[,<dma>]]][[,]<drive_type>]
If there is no ISP16 or compatibles detected, there's probably no harm done.
These options indicate the values that your cdrom drive has been (or will be)
configured to use.
Valid values for the base i/o address are:
port=0x340,0x320,0x330,0x360
for the interrupt request number
irq=0,3,5,7,9,10,11
for the direct memory access line
dma=0,3,5,6,7
and for the type of drive
drive_type=noisp16,Sanyo,Panasonic,Sony,Mitsumi.
Note that these options are case sensitive.
The values 0 for irq and dma indicate that they are not used, and
the drive will be used in 'polling' mode. The values 5 and 7 for irq
should be avoided in order to avoid any conflicts with optional
sound card configuration.
The syntax of the command line does not allow the specification of
irq when there's nothing specified for the base address and no
specification of dma when there is no specification of irq.
The value 'noisp16' for drive_type, which may be used as the first
non-integer option value (e.g. 'isp16=noisp16'), makes sure that probing
for and subsequent configuration of an ISP16-compatible card is skipped
all together. This can be useful to overcome possible conflicts which
may arise while the kernel is probing your hardware.
The default values are
port=0x340
irq=0
dma=0
drive_type=Sanyo
reflecting my own configuration. The defaults can be changed in
the file linux/drivers/cdrom/ips16.h.
The cdrom interface can be configured at run time by loading the
initialisation driver as a module. In that case, the interface
parameters can be set by giving appropriate values on the command
line. Configuring the driver can then be done by the following
command (assuming you have iso16.o installed in a proper place):
insmod isp16.o isp16_cdrom_base=<port> isp16_cdrom_irq=<irq> \
isp16_cdrom_dma=<dma> isp16_cdrom_type=<drive_type>
where port, irq, dma and drive_type can have any of the values mentioned
above.
Have fun!
If you are using the driver as a module, you can specify your ports and IRQs
like
# insmod mcdx.o mcdx=0x300,11,0x304,5
and so on ("address,IRQ" pairs).
This will override the configuration in mcdx.h.
This driver:
o handles XA and (hopefully) multi session CDs as well as
ordinary CDs;
o supports up to 5 drives (of course, you'll need free
IRQs, i/o ports and slots);
o plays audio
This version doesn't support yet:
o shared IRQs (but it seems to be possible - I've successfully
connected two drives to the same irq. So it's `only' a
problem of the driver.)
This driver never will:
o Read digital audio (i.e. copy directly), due to missing
hardware features.
heiko@lotte.sax.de
This is the README file for the Optics Storage 8000 AT CDROM device driver.
This is the driver for the so-called 'DOLPHIN' drive, with the 34-pin
Sony-compatible interface. For the IDE-compatible Optics Storage 8001
drive, you will want the ATAPI CDROM driver. The driver also seems to
work with the Lasermate CR328A. If you have a drive that works with
this driver, and that doesn't report itself as DOLPHIN, please drop me
a mail.
The support for multisession CDs is in ALPHA stage. If you use it,
please mail me your experiences. Multisession support can be disabled
at compile time.
You can find some older versions of the driver at
dutette.et.tudelft.nl:/pub/linux/
and at Eberhard's mirror
ftp.gwdg.de:/pub/linux/cdrom/drivers/optics/
Before you can use the driver, you have to create the device file once:
# mknod /dev/optcd0 b 17 0
To specify the base address if the driver is "compiled-in" to your kernel,
you can use the kernel command line item (LILO option)
optcd=0x340
with the right address.
If you have compiled optcd as a module, you can load it with
# insmod /usr/src/linux/modules/optcd.o
or
# insmod /usr/src/linux/modules/optcd.o optcd=0x340
with the matching address value of your interface card.
The driver employs a number of buffers to do read-ahead and block size
conversion. The number of buffers is configurable in optcd.h, and has
influence on the driver performance. For my machine (a P75), 6 buffers
seems optimal, as can be seen from this table:
#bufs kb/s %cpu
1 97 0.1
2 191 0.3
3 188 0.2
4 246 0.3
5 189 19
6 280 0.4
7 281 7.0
8 246 2.8
16 281 3.4
If you get a throughput significantly below 300 kb/s, try tweaking
N_BUFS, and don't forget to mail me your results!
I'd appreciate success/failure reports. If you find a bug, try
recompiling the driver with some strategically chosen debug options
(these can be found in optcd.h) and include the messages generated in
your bug report. Good luck.
Leo Spiekman (spiekman@dutette.et.tudelft.nl)
此差异已折叠。
-- Documentation/cdrom/sjcd
80% of the work takes 20% of the time,
20% of the work takes 80% of the time...
(Murphy's law)
Once started, training can not be stopped...
(Star Wars)
This is the README for the sjcd cdrom driver, version 1.6.
This file is meant as a tips & tricks edge for the usage of the SANYO CDR-H94A
cdrom drive. It will grow as the questions arise. ;-)
For info on configuring the ISP16 sound card look at Documentation/cdrom/isp16.
The driver should work with any of the Panasonic, Sony or Mitsumi style
CDROM interfaces.
The cdrom interface on Media Magic's soft configurable sound card ISP16,
which used to be included in the driver, is now supported in a separate module.
This initialisation module will probably also work with other interfaces
based on an OPTi 82C928 or 82C929 chip (like MAD16 and Mozart): see the
documentation Documentation/cdrom/isp16.
The device major for sjcd is 18, and minor is 0. Create a block special
file in your /dev directory (e.g., /dev/sjcd) with these numbers.
(For those who don't know, being root and doing the following should do
the trick:
mknod -m 644 /dev/sjcd b 18 0
and mount the cdrom by /dev/sjcd).
The default configuration parameters are:
base address 0x340
no irq
no dma
(Actually the CDR-H94A doesn't know how to use irq and dma.)
As of version 1.2, setting base address at boot time is supported
through the use of command line options: type at the "boot:" prompt:
linux sjcd=<base_address>
(where you would use the kernel labeled "linux" in lilo's configuration
file /etc/lilo.conf). You could also use 'append="sjcd=<configuration_info>"'
in the appropriate section of /etc/lilo.conf
If you're building a kernel yourself you can set your default base
i/o address with SJCD_BASE_ADDR in /usr/src/linux/drivers/cdrom/sjcd.h.
The sjcd driver supports being loaded as a module. The following
command will set the base i/o address on the fly (assuming you
have installed the module in an appropriate place).
insmod sjcd.o sjcd_base=<base_address>
Have fun!
If something is wrong, please email to vadim@rbrf.ru
or vadim@ipsun.ras.ru
or model@cecmow.enet.dec.com
or H.T.M.v.d.Maarel@marin.nl
It happens sometimes that Vadim is not reachable by mail. For these
instances, Eric van der Maarel will help too.
Vadim V. Model, Eric van der Maarel, Eberhard Moenkeberg
README FOR LINUX SONY CDU-535/531 DRIVER
========================================
This is the Sony CDU-535 (and 531) driver version 0.7 for Linux.
I do not think I have the documentation to add features like DMA support
so if anyone else wants to pursue it or help me with it, please do.
(I need to see what was done for the CDU-31A driver -- perhaps I can
steal some of that code.)
This is a Linux device driver for the Sony CDU-535 CDROM drive. This is
one of the older Sony drives with its own interface card (Sony bus).
The DOS driver for this drive is named SONY_CDU.SYS - when you boot DOS
your drive should be identified as a SONY CDU-535. The driver works
with a CDU-531 also. One user reported that the driver worked on drives
OEM'ed by Procomm, drive and interface board were labelled Procomm.
The Linux driver is based on Corey Minyard's sonycd 0.3 driver for
the CDU-31A. Ron Jeppesen just changed the commands that were sent
to the drive to correspond to the CDU-535 commands and registers.
There were enough changes to let bugs creep in but it seems to be stable.
Ron was able to tar an entire CDROM (should read all blocks) and built
ghostview and xfig off Walnut Creek's X11R5/GNU CDROM. xcdplayer and
workman work with the driver. Others have used the driver without
problems except those dealing with wait loops (fixed in third release).
Like Minyard's original driver this one uses a polled interface (this
is also the default setup for the DOS driver). It has not been tried
with interrupts or DMA enabled on the board.
REQUIREMENTS
============
- Sony CDU-535 drive, preferably without interrupts and DMA
enabled on the card.
- Drive must be set up as unit 1. Only the first unit will be
recognized
- You must enter your interface address into
/usr/src/linux/drivers/cdrom/sonycd535.h and build the
appropriate kernel or use the "kernel command line" parameter
sonycd535=0x320
with the correct interface address.
NOTES:
======
1) The drive MUST be turned on when booting or it will not be recognized!
(but see comments on modularized version below)
2) when the cdrom device is opened the eject button is disabled to keep the
user from ejecting a mounted disk and replacing it with another.
Unfortunately xcdplayer and workman also open the cdrom device so you
have to use the eject button in the software. Keep this in mind if your
cdrom player refuses to give up its disk -- exit workman or xcdplayer, or
umount the drive if it has been mounted.
THANKS
======
Many thanks to Ron Jeppesen (ronj.an@site007.saic.com) for getting
this project off the ground. He wrote the initial release
and the first two patches to this driver (0.1, 0.2, and 0.3).
Thanks also to Eberhard Moenkeberg (emoenke@gwdg.de) for prodding
me to place this code into the mainstream Linux source tree
(as of Linux version 1.1.91), as well as some patches to make
it a better device citizen. Further thanks to Joel Katz
<joelkatz@webchat.org> for his MODULE patches (see details below),
Porfiri Claudio <C.Porfiri@nisms.tei.ericsson.se> for patches
to make the driver work with the older CDU-510/515 series, and
Heiko Eissfeldt <heiko@colossus.escape.de> for pointing out that
the verify_area() checks were ignoring the results of said checks
(note: verify_area() has since been replaced by access_ok()).
(Acknowledgments from Ron Jeppesen in the 0.3 release:)
Thanks to Corey Minyard who wrote the original CDU-31A driver on which
this driver is based. Thanks to Ken Pizzini and Bob Blair who provided
patches and feedback on the first release of this driver.
Ken Pizzini
ken@halcyon.com
------------------------------------------------------------------------------
(The following is from Joel Katz <joelkatz@webchat.org>.)
To build a version of sony535.o that can be installed as a module,
use the following command:
gcc -c -D__KERNEL__ -DMODULE -O2 sonycd535.c -o sonycd535.o
To install the module, simply type:
insmod sony535.o
or
insmod sony535.o sonycd535=<address>
And to remove it:
rmmod sony535
The code checks to see if MODULE is defined and behaves as it used
to if MODULE is not defined. That means your patched file should behave
exactly as it used to if compiled into the kernel.
I have an external drive, and I usually leave it powered off. I used
to have to reboot if I needed to use the CDROM drive. Now I don't.
Even if you have an internal drive, why waste the 96K of memory
(unswappable) that the driver uses if you use your CD-ROM drive infrequently?
This driver will not install (whether compiled in or loaded as a
module) if the CDROM drive is not available during its initialization. This
means that you can have the driver compiled into the kernel and still load
the module later (assuming the driver doesn't install itself during
power-on). This only wastes 12K when you boot with the CDROM drive off.
This is what I usually do; I leave the driver compiled into the
kernel, but load it as a module if I powered the system up with the drive
off and then later decided to use the CDROM drive.
Since the driver only uses a single page to point to the chunks,
attempting to set the buffer cache to more than 2 Megabytes would be very
bad; don't do that.
......@@ -9,19 +9,29 @@ for accessing the i2c bus and the gpio pins of the bt8xx chipset.
Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
Compiling kernel please enable:
a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux"
b.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Enable Video for Linux API 1 (DEPRECATED)"
b.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Video Capture Adapters" => "BT848 Video For Linux"
c.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
2) Loading Modules
==================
Please use the following options with care as deselection of drivers which are in fact necessary
may result in DVB devices that cannot be tuned due to lack of driver support:
You can save RAM by deselecting every frontend module that your DVB card does not need.
First please remove the static dependency of DVB card drivers on all frontend modules for all possible card variants by enabling:
d.) "Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Load and attach frontend modules as needed"
In default cases bttv is loaded automatically.
To load the backend either place dvb-bt8xx in etc/modules, or apply manually:
If you know the frontend driver that your card needs please enable:
e.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Customise DVB Frontends" => "Customise the frontend modules to build"
Then please select your card-specific frontend module.
$ modprobe dvb-bt8xx
2) Loading Modules
==================
All frontends will be loaded automatically.
Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically.
Exceptions are:
- Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom.
People running udev please see Documentation/dvb/udev.txt.
In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary:
......@@ -30,7 +40,6 @@ In the following cases overriding the PCI type detection for dvb-bt8xx might be
------------------------------
$ modprobe bttv card=113
$ modprobe dvb-bt8xx
$ modprobe dst
Useful parameters for verbosity level and debugging the dst module:
......@@ -65,10 +74,9 @@ DViCO FusionHDTV 5 Lite: 135
Notice: The order of the card ID should be uprising:
Example:
$ modprobe bttv card=113 card=135
$ modprobe dvb-bt8xx
For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
In case of further problems send questions to the mailing list: www.linuxdvb.org.
In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org.
Authors: Richard Walker,
Jamie Honan,
......
......@@ -24,7 +24,8 @@ use IO::Handle;
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird");
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1");
# Check args
syntax() if (scalar(@ARGV) != 1);
......@@ -56,7 +57,7 @@ syntax();
sub sp8870 {
my $sourcefile = "tt_Premium_217g.zip";
my $url = "http://www.technotrend.de/new/217g/$sourcefile";
my $url = "http://www.softwarepatch.pl/9999ccd06a4813cb827dbb0005071c71/$sourcefile";
my $hash = "53970ec17a538945a6d8cb608a7b3899";
my $outfile = "dvb-fe-sp8870.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
......@@ -210,6 +211,45 @@ sub dec3000s {
$outfile;
}
sub opera1{
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
checkstandard();
my $fwfile1="dvb-usb-opera1-fpga-01.fw";
my $fwfile2="dvb-usb-opera-01.fw";
extract("2830SCap2.sys", 0x62e8, 55024, "$tmpdir/opera1-fpga.fw");
extract("2830SLoad2.sys",0x3178,0x3685-0x3178,"$tmpdir/fw1part1");
extract("2830SLoad2.sys",0x0980,0x3150-0x0980,"$tmpdir/fw1part2");
delzero("$tmpdir/fw1part1","$tmpdir/fw1part1-1");
delzero("$tmpdir/fw1part2","$tmpdir/fw1part2-1");
verify("$tmpdir/fw1part1-1","5e0909858fdf0b5b09ad48b9fe622e70");
verify("$tmpdir/fw1part2-1","d6e146f321427e931df2c6fcadac37a1");
verify("$tmpdir/opera1-fpga.fw","0f8133f5e9051f5f3c1928f7e5a1b07d");
my $RES1="\x01\x92\x7f\x00\x01\x00";
my $RES0="\x01\x92\x7f\x00\x00\x00";
my $DAT1="\x01\x00\xe6\x00\x01\x00";
my $DAT0="\x01\x00\xe6\x00\x00\x00";
open FW,">$tmpdir/opera.fw";
print FW "$RES1";
print FW "$DAT1";
print FW "$RES1";
print FW "$DAT1";
appendfile(FW,"$tmpdir/fw1part1-1");
print FW "$RES0";
print FW "$DAT0";
print FW "$RES1";
print FW "$DAT1";
appendfile(FW,"$tmpdir/fw1part2-1");
print FW "$RES1";
print FW "$DAT1";
print FW "$RES0";
print FW "$DAT0";
copy ("$tmpdir/opera1-fpga.fw",$fwfile1);
copy ("$tmpdir/opera.fw",$fwfile2);
$fwfile1.",".$fwfile2;
}
sub vp7041 {
my $sourcefile = "2.422.zip";
......@@ -440,6 +480,25 @@ sub appendfile {
close(INFILE);
}
sub delzero{
my ($infile,$outfile) =@_;
open INFILE,"<$infile";
open OUTFILE,">$outfile";
while (1){
$rcount=sysread(INFILE,$buf,22);
$len=ord(substr($buf,0,1));
print OUTFILE substr($buf,0,1);
print OUTFILE substr($buf,2,$len+3);
last if ($rcount<1);
printf OUTFILE "%c",0;
#print $len." ".length($buf)."\n";
}
close(INFILE);
close(OUTFILE);
}
sub syntax() {
print STDERR "syntax: get_dvb_firmware <component>\n";
print STDERR "Supported components:\n";
......
To extract the firmware for the Opera DVB-S1 USB-Box
you need to copy the files:
2830SCap2.sys
2830SLoad2.sys
from the windriver disk into this directory.
Then run
./get_dvb_firware opera1
and after that you have 2 files:
dvb-usb-opera-01.fw
dvb-usb-opera1-fpga-01.fw
in here.
Copy them into /lib/firmware/ .
After that the driver can load the firmware
(if you have enabled firmware loading
in kernel config and have hotplug running).
Marco Gittler <g.marco@freenet.de>
\ No newline at end of file
#!/bin/bash
echo 1 > /proc/self/make-it-fail
exec $*
#!/bin/bash
#
# Usage: failmodule <failname> <modulename> [stacktrace-depth]
#
# <failname>: "failslab", "fail_alloc_page", or "fail_make_request"
#
# <modulename>: module name that you want to inject faults.
#
# [stacktrace-depth]: the maximum number of stacktrace walking allowed
#
STACKTRACE_DEPTH=5
if [ $# -gt 2 ]; then
STACKTRACE_DEPTH=$3
fi
if [ ! -d /debug/$1 ]; then
echo "Fault-injection $1 does not exist" >&2
exit 1
fi
if [ ! -d /sys/module/$2 ]; then
echo "Module $2 does not exist" >&2
exit 1
fi
# Disable any fault injection
echo 0 > /debug/$1/stacktrace-depth
echo `cat /sys/module/$2/sections/.text` > /debug/$1/require-start
echo `cat /sys/module/$2/sections/.exit.text` > /debug/$1/require-end
echo $STACKTRACE_DEPTH > /debug/$1/stacktrace-depth
......@@ -103,6 +103,11 @@ configuration of fault-injection capabilities.
default is 'N', setting it to 'Y' will inject failures
only into non-sleep allocations (GFP_ATOMIC allocations).
- /debug/fail_page_alloc/min-order:
specifies the minimum page allocation order to be injected
failures.
o Boot option
In order to inject faults while debugfs is not available (early boot time),
......@@ -156,70 +161,77 @@ o add a hook to insert failures
Application Examples
--------------------
o inject slab allocation failures into module init/cleanup code
o Inject slab allocation failures into module init/exit code
------------------------------------------------------------------------------
#!/bin/bash
FAILCMD=Documentation/fault-injection/failcmd.sh
BLACKLIST="root_plug evbug"
FAILNAME=failslab
echo Y > /debug/$FAILNAME/task-filter
echo 10 > /debug/$FAILNAME/probability
echo 100 > /debug/$FAILNAME/interval
echo -1 > /debug/$FAILNAME/times
echo 2 > /debug/$FAILNAME/verbose
echo 1 > /debug/$FAILNAME/ignore-gfp-wait
FAILTYPE=failslab
echo Y > /debug/$FAILTYPE/task-filter
echo 10 > /debug/$FAILTYPE/probability
echo 100 > /debug/$FAILTYPE/interval
echo -1 > /debug/$FAILTYPE/times
echo 0 > /debug/$FAILTYPE/space
echo 2 > /debug/$FAILTYPE/verbose
echo 1 > /debug/$FAILTYPE/ignore-gfp-wait
blacklist()
faulty_system()
{
echo $BLACKLIST | grep $1 > /dev/null 2>&1
bash -c "echo 1 > /proc/self/make-it-fail && exec $*"
}
oops()
{
dmesg | grep BUG > /dev/null 2>&1
}
if [ $# -eq 0 ]
then
echo "Usage: $0 modulename [ modulename ... ]"
exit 1
fi
for m in $*
do
echo inserting $m...
faulty_system modprobe $m
find /lib/modules/`uname -r` -name '*.ko' -exec basename {} .ko \; |
while read i
do
oops && exit 1
if ! blacklist $i
then
echo inserting $i...
bash $FAILCMD modprobe $i
fi
done
lsmod | awk '{ if ($3 == 0) { print $1 } }' |
while read i
do
oops && exit 1
if ! blacklist $i
then
echo removing $i...
bash $FAILCMD modprobe -r $i
fi
done
echo removing $m...
faulty_system modprobe -r $m
done
------------------------------------------------------------------------------
o inject slab allocation failures only for a specific module
o Inject page allocation failures only for a specific module
------------------------------------------------------------------------------
#!/bin/bash
FAILMOD=Documentation/fault-injection/failmodule.sh
FAILTYPE=fail_page_alloc
module=$1
echo injecting errors into the module $1...
if [ -z $module ]
then
echo "Usage: $0 <modulename>"
exit 1
fi
modprobe $1
bash $FAILMOD failslab $1 10
echo 25 > /debug/failslab/probability
modprobe $module
------------------------------------------------------------------------------
if [ ! -d /sys/module/$module/sections ]
then
echo Module $module is not loaded
exit 1
fi
cat /sys/module/$module/sections/.text > /debug/$FAILTYPE/require-start
cat /sys/module/$module/sections/.data > /debug/$FAILTYPE/require-end
echo N > /debug/$FAILTYPE/task-filter
echo 10 > /debug/$FAILTYPE/probability
echo 100 > /debug/$FAILTYPE/interval
echo -1 > /debug/$FAILTYPE/times
echo 0 > /debug/$FAILTYPE/space
echo 2 > /debug/$FAILTYPE/verbose
echo 1 > /debug/$FAILTYPE/ignore-gfp-wait
echo 1 > /debug/$FAILTYPE/ignore-gfp-highmem
echo 10 > /debug/$FAILTYPE/stacktrace-depth
trap "echo 0 > /debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT
echo "Injecting errors into the module $module... (interrupt to stop)"
sleep 1000000
......@@ -41,24 +41,6 @@ Who: Pavel Machek <pavel@suse.cz>
---------------------------
What: RAW driver (CONFIG_RAW_DRIVER)
When: December 2005
Why: declared obsolete since kernel 2.6.3
O_DIRECT can be used instead
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
When: June 2007
Why: Deprecated in favour of the more efficient and robust rawiso interface.
Affected are applications which use the deprecated part of libraw1394
(raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv,
raw1394_stop_iso_rcv) or bypass libraw1394.
Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
---------------------------
What: old NCR53C9x driver
When: October 2007
Why: Replaced by the much better esp_scsi driver. Actual low-level
......@@ -129,13 +111,6 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: drivers depending on OSS_OBSOLETE_DRIVER
When: options in 2.6.20, code in 2.6.22
Why: OSS drivers with ALSA replacements
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
(temporary transition config option provided until then)
The transition config option will also be removed at the same time.
......@@ -206,28 +181,6 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
When: December 2006
Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
functionally very much similar. They talk to ACPI in same way. Only
difference between them is the way they do frequency transitions.
One uses MSRs and the other one uses IO ports. Functionaliy of
speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
That means one common driver will support all Intel Enhanced Speedstep
capable CPUs. That means less confusion over name of
speedstep-centrino driver (with that driver supposed to be used on
non-centrino platforms). That means less duplication of code and
less maintenance effort and no possibility of these two drivers
going out of sync.
Current users of speedstep_centrino with ACPI hooks are requested to
switch over to acpi-cpufreq driver. speedstep-centrino will continue
to work using older non-ACPI static table based scheme even after this
date.
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
---------------------------
What: /sys/firmware/acpi/namespace
When: 2.6.21
Why: The ACPI namespace is effectively the symbol list for
......@@ -258,14 +211,6 @@ Who: Len Brown <len.brown@intel.com>
---------------------------
What: sk98lin network driver
When: July 2007
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
replaced by the skge driver.
Who: Stephen Hemminger <shemminger@osdl.org>
---------------------------
What: Compaq touchscreen device emulation
When: Oct 2007
Files: drivers/input/tsdev.c
......@@ -280,25 +225,6 @@ Who: Richard Purdie <rpurdie@rpsys.net>
---------------------------
What: Multipath cached routing support in ipv4
When: in 2.6.23
Why: Code was merged, then submitter immediately disappeared leaving
us with no maintainer and lots of bugs. The code should not have
been merged in the first place, and many aspects of it's
implementation are blocking more critical core networking
development. It's marked EXPERIMENTAL and no distribution
enables it because it cause obscure crashes due to unfixable bugs
(interfaces don't return errors so memory allocation can't be
handled, calling contexts of these interfaces make handling
errors impossible too because they get called after we've
totally commited to creating a route object, for example).
This problem has existed for years and no forward progress
has ever been made, and nobody steps up to try and salvage
this code, so we're going to finally just get rid of it.
Who: David S. Miller <davem@davemloft.net>
---------------------------
What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer)
When: December 2007
Why: These functions are a leftover from 2.4 times. They have several
......@@ -323,6 +249,14 @@ Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: 'time' kernel boot parameter
When: January 2008
Why: replaced by 'printk.time=<value>' so that printk timestamps can be
enabled or disabled as needed
Who: Randy Dunlap <randy.dunlap@oracle.com>
---------------------------
What: drivers depending on OSS_OBSOLETE
When: options in 2.6.23, code in 2.6.25
Why: obsolete OSS drivers
......@@ -348,3 +282,31 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
What: Legacy RTC drivers (under drivers/i2c/chips)
When: November 2007
Why: Obsolete. We have a RTC subsystem with better drivers.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: iptables SAME target
When: 1.1. 2008
Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h
Why: Obsolete for multiple years now, NAT core provides the same behaviour.
Unfixable broken wrt. 32/64 bit cleanness.
Who: Patrick McHardy <kaber@trash.net>
---------------------------
What: The arch/ppc and include/asm-ppc directories
When: Jun 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
platforms. Currently there are efforts underway to port the remaining
arch/ppc platforms to the merged tree. New submissions to the arch/ppc
tree have been frozen with the 2.6.22 kernel release and that tree will
remain in bug-fix only mode until its scheduled removal. Platforms
that are not ported by June 2008 will be removed due to the lack of an
interested maintainer.
Who: linuxppc-dev@ozlabs.org
---------------------------
......@@ -238,6 +238,8 @@ config_item_type.
struct config_group *(*make_group)(struct config_group *group,
const char *name);
int (*commit_item)(struct config_item *item);
void (*disconnect_notify)(struct config_group *group,
struct config_item *item);
void (*drop_item)(struct config_group *group,
struct config_item *item);
};
......@@ -268,6 +270,16 @@ the item in other threads, the memory is safe. It may take some time
for the item to actually disappear from the subsystem's usage. But it
is gone from configfs.
When drop_item() is called, the item's linkage has already been torn
down. It no longer has a reference on its parent and has no place in
the item hierarchy. If a client needs to do some cleanup before this
teardown happens, the subsystem can implement the
ct_group_ops->disconnect_notify() method. The method is called after
configfs has removed the item from the filesystem view but before the
item is removed from its parent group. Like drop_item(),
disconnect_notify() is void and cannot fail. Client subsystems should
not drop any references here, as they still must do it in drop_item().
A config_group cannot be removed while it still has child items. This
is implemented in the configfs rmdir(2) code. ->drop_item() will not be
called, as the item has not been dropped. rmdir(2) will fail, as the
......@@ -280,18 +292,18 @@ tells configfs to make the subsystem appear in the file tree.
struct configfs_subsystem {
struct config_group su_group;
struct semaphore su_sem;
struct mutex su_mutex;
};
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
A subsystem consists of a toplevel config_group and a semaphore.
A subsystem consists of a toplevel config_group and a mutex.
The group is where child config_items are created. For a subsystem,
this group is usually defined statically. Before calling
configfs_register_subsystem(), the subsystem must have initialized the
group via the usual group _init() functions, and it must also have
initialized the semaphore.
initialized the mutex.
When the register call returns, the subsystem is live, and it
will be visible via configfs. At that point, mkdir(2) can be called and
the subsystem must be ready for it.
......@@ -303,7 +315,7 @@ subsystem/group and the simple_child item in configfs_example.c It
shows a trivial object displaying and storing an attribute, and a simple
group creating and destroying these children.
[Hierarchy Navigation and the Subsystem Semaphore]
[Hierarchy Navigation and the Subsystem Mutex]
There is an extra bonus that configfs provides. The config_groups and
config_items are arranged in a hierarchy due to the fact that they
......@@ -314,19 +326,19 @@ and config_item->ci_parent structure members.
A subsystem can navigate the cg_children list and the ci_parent pointer
to see the tree created by the subsystem. This can race with configfs'
management of the hierarchy, so configfs uses the subsystem semaphore to
management of the hierarchy, so configfs uses the subsystem mutex to
protect modifications. Whenever a subsystem wants to navigate the
hierarchy, it must do so under the protection of the subsystem
semaphore.
mutex.
A subsystem will be prevented from acquiring the semaphore while a newly
A subsystem will be prevented from acquiring the mutex while a newly
allocated item has not been linked into this hierarchy. Similarly, it
will not be able to acquire the semaphore while a dropping item has not
will not be able to acquire the mutex while a dropping item has not
yet been unlinked. This means that an item's ci_parent pointer will
never be NULL while the item is in configfs, and that an item will only
be in its parent's cg_children list for the same duration. This allows
a subsystem to trust ci_parent and cg_children while they hold the
semaphore.
mutex.
[Item Aggregation Via symlink(2)]
......@@ -386,6 +398,33 @@ As a consequence of this, default_groups cannot be removed directly via
rmdir(2). They also are not considered when rmdir(2) on the parent
group is checking for children.
[Dependant Subsystems]
Sometimes other drivers depend on particular configfs items. For
example, ocfs2 mounts depend on a heartbeat region item. If that
region item is removed with rmdir(2), the ocfs2 mount must BUG or go
readonly. Not happy.
configfs provides two additional API calls: configfs_depend_item() and
configfs_undepend_item(). A client driver can call
configfs_depend_item() on an existing item to tell configfs that it is
depended on. configfs will then return -EBUSY from rmdir(2) for that
item. When the item is no longer depended on, the client driver calls
configfs_undepend_item() on it.
These API cannot be called underneath any configfs callbacks, as
they will conflict. They can block and allocate. A client driver
probably shouldn't calling them of its own gumption. Rather it should
be providing an API that external subsystems call.
How does this work? Imagine the ocfs2 mount process. When it mounts,
it asks for a heartbeat region item. This is done via a call into the
heartbeat code. Inside the heartbeat code, the region item is looked
up. Here, the heartbeat code calls configfs_depend_item(). If it
succeeds, then heartbeat knows the region is safe to give to ocfs2.
If it fails, it was being torn down anyway, and heartbeat can gracefully
pass up an error.
[Committable Items]
NOTE: Committable items are currently unimplemented.
......
......@@ -453,7 +453,7 @@ static int __init configfs_example_init(void)
subsys = example_subsys[i];
config_group_init(&subsys->su_group);
init_MUTEX(&subsys->su_sem);
mutex_init(&subsys->su_mutex);
ret = configfs_register_subsystem(subsys);
if (ret) {
printk(KERN_ERR "Error %d while registering subsystem %s\n",
......
......@@ -171,7 +171,9 @@ read the file /proc/PID/status:
This shows you nearly the same information you would get if you viewed it with
the ps command. In fact, ps uses the proc file system to obtain its
information. The statm file contains more detailed information about the
process memory usage. Its seven fields are explained in Table 1-2.
process memory usage. Its seven fields are explained in Table 1-2. The stat
file contains details information about the process itself. Its fields are
explained in Table 1-3.
Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
......@@ -188,16 +190,65 @@ Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
dt number of dirty pages (always 0 on 2.6)
..............................................................................
Table 1-3: Contents of the stat files (as of 2.6.22-rc3)
..............................................................................
Field Content
pid process id
tcomm filename of the executable
state state (R is running, S is sleeping, D is sleeping in an
uninterruptible wait, Z is zombie, T is traced or stopped)
ppid process id of the parent process
pgrp pgrp of the process
sid session id
tty_nr tty the process uses
tty_pgrp pgrp of the tty
flags task flags
min_flt number of minor faults
cmin_flt number of minor faults with child's
maj_flt number of major faults
cmaj_flt number of major faults with child's
utime user mode jiffies
stime kernel mode jiffies
cutime user mode jiffies with child's
cstime kernel mode jiffies with child's
priority priority level
nice nice level
num_threads number of threads
start_time time the process started after system boot
vsize virtual memory size
rss resident set memory size
rsslim current limit in bytes on the rss
start_code address above which program text can run
end_code address below which program text can run
start_stack address of the start of the stack
esp current value of ESP
eip current value of EIP
pending bitmap of pending signals (obsolete)
blocked bitmap of blocked signals (obsolete)
sigign bitmap of ignored signals (obsolete)
sigcatch bitmap of catched signals (obsolete)
wchan address where process went to sleep
0 (place holder)
0 (place holder)
exit_signal signal to send to parent thread on exit
task_cpu which CPU the task is scheduled on
rt_priority realtime priority
policy scheduling policy (man sched_setscheduler)
blkio_ticks time spent waiting for block IO
..............................................................................
1.2 Kernel data
---------------
Similar to the process entries, the kernel data files give information about
the running kernel. The files used to obtain this information are contained in
/proc and are listed in Table 1-3. Not all of these will be present in your
/proc and are listed in Table 1-4. Not all of these will be present in your
system. It depends on the kernel configuration and the loaded modules, which
files are there, and which are missing.
Table 1-3: Kernel info in /proc
Table 1-4: Kernel info in /proc
..............................................................................
File Content
apm Advanced power management info
......@@ -473,10 +524,10 @@ IDE devices:
More detailed information can be found in the controller specific
subdirectories. These are named ide0, ide1 and so on. Each of these
directories contains the files shown in table 1-4.
directories contains the files shown in table 1-5.
Table 1-4: IDE controller info in /proc/ide/ide?
Table 1-5: IDE controller info in /proc/ide/ide?
..............................................................................
File Content
channel IDE channel (0 or 1)
......@@ -486,11 +537,11 @@ Table 1-4: IDE controller info in /proc/ide/ide?
..............................................................................
Each device connected to a controller has a separate subdirectory in the
controllers directory. The files listed in table 1-5 are contained in these
controllers directory. The files listed in table 1-6 are contained in these
directories.
Table 1-5: IDE device information
Table 1-6: IDE device information
..............................................................................
File Content
cache The cache
......@@ -1297,6 +1348,21 @@ nr_hugepages configures number of hugetlb page reserved for the system.
hugetlb_shm_group contains group id that is allowed to create SysV shared
memory segment using hugetlb page.
hugepages_treat_as_movable
--------------------------
This parameter is only useful when kernelcore= is specified at boot time to
create ZONE_MOVABLE for pages that may be reclaimed or migrated. Huge pages
are not movable so are not normally allocated from ZONE_MOVABLE. A non-zero
value written to hugepages_treat_as_movable allows huge pages to be allocated
from ZONE_MOVABLE.
Once enabled, the ZONE_MOVABLE is treated as an area of memory the huge
pages pool can easily grow or shrink within. Assuming that applications are
not running that mlock() a lot of memory, it is likely the huge pages pool
can grow to the size of ZONE_MOVABLE by repeatedly entering the desired value
into nr_hugepages and triggering page reclaim.
laptop_mode
-----------
......
......@@ -3,7 +3,7 @@
Original author: Richard Gooch <rgooch@atnf.csiro.au>
Last updated on October 28, 2005
Last updated on June 24, 2007.
Copyright (C) 1999 Richard Gooch
Copyright (C) 2005 Pekka Enberg
......@@ -107,7 +107,7 @@ file /proc/filesystems.
struct file_system_type
-----------------------
This describes the filesystem. As of kernel 2.6.13, the following
This describes the filesystem. As of kernel 2.6.22, the following
members are defined:
struct file_system_type {
......@@ -119,6 +119,8 @@ struct file_system_type {
struct module *owner;
struct file_system_type * next;
struct list_head fs_supers;
struct lock_class_key s_lock_key;
struct lock_class_key s_umount_key;
};
name: the name of the filesystem type, such as "ext2", "iso9660",
......@@ -137,11 +139,12 @@ struct file_system_type {
next: for internal VFS use: you should initialize this to NULL
s_lock_key, s_umount_key: lockdep-specific
The get_sb() method has the following arguments:
struct super_block *sb: the superblock structure. This is partially
initialized by the VFS and the rest must be initialized by the
get_sb() method
struct file_system_type *fs_type: decribes the filesystem, partly initialized
by the specific filesystem code
int flags: mount flags
......@@ -150,12 +153,13 @@ The get_sb() method has the following arguments:
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
struct vfsmount *mnt: a vfs-internal representation of a mount point
The get_sb() method must determine if the block device specified
in the superblock contains a filesystem of the type the method
supports. On success the method returns the superblock pointer, on
failure it returns NULL.
in the dev_name and fs_type contains a filesystem of the type the method
supports. If it succeeds in opening the named block device, it initializes a
struct super_block descriptor for the filesystem contained by the block device.
On failure it returns an error.
The most interesting member of the superblock structure that the
get_sb() method fills in is the "s_op" field. This is a pointer to
......@@ -193,7 +197,7 @@ struct super_operations
-----------------------
This describes how the VFS can manipulate the superblock of your
filesystem. As of kernel 2.6.13, the following members are defined:
filesystem. As of kernel 2.6.22, the following members are defined:
struct super_operations {
struct inode *(*alloc_inode)(struct super_block *sb);
......@@ -216,8 +220,6 @@ struct super_operations {
void (*clear_inode) (struct inode *);
void (*umount_begin) (struct super_block *);
void (*sync_inodes) (struct super_block *sb,
struct writeback_control *wbc);
int (*show_options)(struct seq_file *, struct vfsmount *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
......@@ -300,9 +302,6 @@ or bottom half).
umount_begin: called when the VFS is unmounting a filesystem.
sync_inodes: called when the VFS is writing out dirty data associated with
a superblock.
show_options: called by the VFS to show mount options for /proc/<pid>/mounts.
quota_read: called by the VFS to read from filesystem quota file.
......@@ -324,7 +323,7 @@ struct inode_operations
-----------------------
This describes how the VFS can manipulate an inode in your
filesystem. As of kernel 2.6.13, the following members are defined:
filesystem. As of kernel 2.6.22, the following members are defined:
struct inode_operations {
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
......@@ -348,6 +347,7 @@ struct inode_operations {
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*removexattr) (struct dentry *, const char *);
void (*truncate_range)(struct inode *, loff_t, loff_t);
};
Again, all methods are called without any locks being held, unless
......@@ -444,6 +444,9 @@ otherwise noted.
removexattr: called by the VFS to remove an extended attribute from
a file. This method is called by removexattr(2) system call.
truncate_range: a method provided by the underlying filesystem to truncate a
range of blocks , i.e. punch a hole somewhere in a file.
The Address Space Object
========================
......@@ -522,7 +525,7 @@ struct address_space_operations
-------------------------------
This describes how the VFS can manipulate mapping of a file to page cache in
your filesystem. As of kernel 2.6.16, the following members are defined:
your filesystem. As of kernel 2.6.22, the following members are defined:
struct address_space_operations {
int (*writepage)(struct page *page, struct writeback_control *wbc);
......@@ -543,6 +546,7 @@ struct address_space_operations {
int);
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
};
writepage: called by the VM to write a dirty page to backing store.
......@@ -689,6 +693,10 @@ struct address_space_operations {
transfer any private data across and update any references
that it has to the page.
launder_page: Called before freeing a page - it writes back the dirty page. To
prevent redirtying the page, it is kept locked during the whole
operation.
The File Object
===============
......@@ -699,9 +707,10 @@ struct file_operations
----------------------
This describes how the VFS can manipulate an open file. As of kernel
2.6.17, the following members are defined:
2.6.22, the following members are defined:
struct file_operations {
struct module *owner;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
......@@ -728,10 +737,8 @@ struct file_operations {
int (*check_flags)(int);
int (*dir_notify)(struct file *filp, unsigned long arg);
int (*flock) (struct file *, int, struct file_lock *);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned
int);
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned
int);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
};
Again, all methods are called without any locks being held, unless
......
......@@ -78,6 +78,7 @@ static CLASS_DEVICE_ATTR(loading, 0644,
firmware_loading_show, firmware_loading_store);
static ssize_t firmware_data_read(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
......@@ -88,6 +89,7 @@ static ssize_t firmware_data_read(struct kobject *kobj,
return count;
}
static ssize_t firmware_data_write(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
......
......@@ -67,3 +67,7 @@ executed on expiry.
Thomas, Ingo
Added flag to indicate 'deferrable timer' in /proc/timer_stats. A deferrable
timer will appear as follows
10D, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
......@@ -5,8 +5,8 @@ Supported adapters:
'810' and '810E' chipsets)
* Intel 82801BA (ICH2 - part of the '815E' chipset)
* Intel 82801CA/CAM (ICH3)
* Intel 82801DB (ICH4) (HW PEC supported, 32 byte buffer not supported)
* Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported)
* Intel 82801DB (ICH4) (HW PEC supported)
* Intel 82801EB/ER (ICH5) (HW PEC supported)
* Intel 6300ESB
* Intel 82801FB/FR/FW/FRW (ICH6)
* Intel 82801G (ICH7)
......
......@@ -6,7 +6,7 @@ Supported adapters:
Datasheet: Publicly available at the Intel website
* ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
Datasheet: Only available via NDA from ServerWorks
* ATI IXP200, IXP300, IXP400 and SB600 southbridges
* ATI IXP200, IXP300, IXP400, SB600 and SB700 southbridges
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com
......
Kernel driver i2c-taos-evm
Author: Jean Delvare <khali@linux-fr.org>
This is a driver for the evaluation modules for TAOS I2C/SMBus chips.
The modules include an SMBus master with limited capabilities, which can
be controlled over the serial port. Virtually all evaluation modules
are supported, but a few lines of code need to be added for each new
module to instantiate the right I2C chip on the bus. Obviously, a driver
for the chip in question is also needed.
Currently supported devices are:
* TAOS TSL2550 EVM
For addtional information on TAOS products, please see
http://www.taosinc.com/
Using this driver
-----------------
In order to use this driver, you'll need the serport driver, and the
inputattach tool, which is part of the input-utils package. The following
commands will tell the kernel that you have a TAOS EVM on the first
serial port:
# modprobe serport
# inputattach --taos-evm /dev/ttyS0
Technical details
-----------------
Only 4 SMBus transaction types are supported by the TAOS evaluation
modules:
* Receive Byte
* Send Byte
* Read Byte
* Write Byte
The communication protocol is text-based and pretty simple. It is
described in a PDF document on the CD which comes with the evaluation
module. The communication is rather slow, because the serial port has
to operate at 1200 bps. However, I don't think this is a big concern in
practice, as these modules are meant for evaluation and testing only.
......@@ -99,7 +99,7 @@ And then read the data
or
count = i2c_smbus_read_i2c_block_data(fd, 0x84, buffer);
count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer);
The block read should read 16 bytes.
0x84 is the block read command.
......
Kernel driver x1205
===================
Supported chips:
* Xicor X1205 RTC
Prefix: 'x1205'
Addresses scanned: none
Datasheet: http://www.intersil.com/cda/deviceinfo/0,1477,X1205,00.html
Authors:
Karen Spearel <kas11@tampabay.rr.com>,
Alessandro Zummo <a.zummo@towertech.it>
Description
-----------
This module aims to provide complete access to the Xicor X1205 RTC.
Recently Xicor has merged with Intersil, but the chip is
still sold under the Xicor brand.
This chip is located at address 0x6f and uses a 2-byte register addressing.
Two bytes need to be written to read a single register, while most
other chips just require one and take the second one as the data
to be written. To prevent corrupting unknown chips, the user must
explicitely set the probe parameter.
example:
modprobe x1205 probe=0,0x6f
The module supports one more option, hctosys, which is used to set the
software clock from the x1205. On systems where the x1205 is the
only hardware rtc, this parameter could be used to achieve a correct
date/time earlier in the system boot sequence.
example:
modprobe x1205 probe=0,0x6f hctosys=1
......@@ -67,7 +67,6 @@ i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers
Algorithm drivers
-----------------
i2c-algo-8xx: An algorithm for CPM's I2C device in Motorola 8xx processors (NOT BUILT BY DEFAULT)
i2c-algo-bit: A bit-banging algorithm
i2c-algo-pcf: A PCF 8584 style algorithm
i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT)
......@@ -81,6 +80,5 @@ i2c-pcf-epp: PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatch
i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT)
i2c-pport: Primitive parallel port adapter (uses i2c-algo-bit)
i2c-rpx: RPX board Motorola 8xx I2C device (uses i2c-algo-8xx) (NOT BUILT BY DEFAULT)
i2c-velleman: Velleman K8000 parallel port adapter (uses i2c-algo-bit)
......@@ -571,7 +571,7 @@ SMBus communication
u8 command, u8 length,
u8 *values);
extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
u8 command, u8 *values);
u8 command, u8 length, u8 *values);
These ones were removed in Linux 2.6.10 because they had no users, but could
be added back later if needed:
......
......@@ -37,6 +37,7 @@ Offset Type Description
0x1d0 unsigned long EFI memory descriptor map pointer
0x1d4 unsigned long EFI memory descriptor map size
0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb
0x1e4 unsigned long Scratch field for the kernel setup code
0x1e8 char number of entries in E820MAP (below)
0x1e9 unsigned char number of entries in EDDBUF (below)
0x1ea unsigned char number of entries in EDD_MBR_SIG_BUFFER (below)
......
此差异已折叠。
......@@ -112,6 +112,18 @@ POTENTIAL ATTRIBUTE ALIASING CASES
The /dev/mem mmap constraints apply.
mmap of /proc/bus/pci/.../??.?
This is an MMIO mmap of PCI functions, which additionally may or
may not be requested as using the WC attribute.
If WC is requested, and the region in kern_memmap is either WC
or UC, and the EFI memory map designates the region as WC, then
the WC mapping is allowed.
Otherwise, the user mapping must use the same attribute as the
kernel mapping.
read/write of /dev/mem
This uses copy_from_user(), which implicitly uses a kernel
......
......@@ -67,7 +67,7 @@ Code Seq# Include File Comments
0x00 00-1F linux/wavefront.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
0x04 all linux/umsdos_fs.h
0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these.
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
......@@ -55,3 +55,4 @@
54 -> Norwood Micro TV Tuner
55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980]
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390]
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册