mirror of
https://github.com/torvalds/linux.git
synced 2024-11-29 07:31:29 +00:00
Merge branch 'master' of /repos/git/net-next-2.6
Signed-off-by: Patrick McHardy <kaber@trash.net>
This commit is contained in:
Patrick McHardy
commit
9ab99d5a43
1
.gitignore
vendored
1
.gitignore
vendored
@ -37,6 +37,7 @@ modules.builtin
|
||||
tags
|
||||
TAGS
|
||||
vmlinux
|
||||
vmlinuz
|
||||
System.map
|
||||
Module.markers
|
||||
Module.symvers
|
||||
|
||||
@ -144,7 +144,7 @@ usage should require reading the full document.
|
||||
this though and the recommendation to allow only a single
|
||||
interface in STA mode at first!
|
||||
</para>
|
||||
!Finclude/net/mac80211.h ieee80211_if_init_conf
|
||||
!Finclude/net/mac80211.h ieee80211_vif
|
||||
</chapter>
|
||||
|
||||
<chapter id="rx-tx">
|
||||
|
||||
@ -174,7 +174,7 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
static struct mtd_info *board_mtd;
|
||||
static unsigned long baseaddr;
|
||||
static void __iomem *baseaddr;
|
||||
</programlisting>
|
||||
<para>
|
||||
Static example
|
||||
@ -182,7 +182,7 @@ static unsigned long baseaddr;
|
||||
<programlisting>
|
||||
static struct mtd_info board_mtd;
|
||||
static struct nand_chip board_chip;
|
||||
static unsigned long baseaddr;
|
||||
static void __iomem *baseaddr;
|
||||
</programlisting>
|
||||
</sect1>
|
||||
<sect1 id="Partition_defines">
|
||||
@ -283,8 +283,8 @@ int __init board_init (void)
|
||||
}
|
||||
|
||||
/* map physical address */
|
||||
baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
|
||||
if(!baseaddr){
|
||||
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
|
||||
if (!baseaddr) {
|
||||
printk("Ioremap to access NAND chip failed\n");
|
||||
err = -EIO;
|
||||
goto out_mtd;
|
||||
@ -316,7 +316,7 @@ int __init board_init (void)
|
||||
goto out;
|
||||
|
||||
out_ior:
|
||||
iounmap((void *)baseaddr);
|
||||
iounmap(baseaddr);
|
||||
out_mtd:
|
||||
kfree (board_mtd);
|
||||
out:
|
||||
@ -341,7 +341,7 @@ static void __exit board_cleanup (void)
|
||||
nand_release (board_mtd);
|
||||
|
||||
/* unmap physical address */
|
||||
iounmap((void *)baseaddr);
|
||||
iounmap(baseaddr);
|
||||
|
||||
/* Free the MTD device structure */
|
||||
kfree (board_mtd);
|
||||
|
||||
@ -157,7 +157,7 @@ For such memory, you can do things like
|
||||
* access only the 640k-1MB area, so anything else
|
||||
* has to be remapped.
|
||||
*/
|
||||
char * baseptr = ioremap(0xFC000000, 1024*1024);
|
||||
void __iomem *baseptr = ioremap(0xFC000000, 1024*1024);
|
||||
|
||||
/* write a 'A' to the offset 10 of the area */
|
||||
writeb('A',baseptr+10);
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
00-INDEX
|
||||
- This file
|
||||
as-iosched.txt
|
||||
- Anticipatory IO scheduler
|
||||
barrier.txt
|
||||
- I/O Barriers
|
||||
biodoc.txt
|
||||
|
||||
@ -1,172 +0,0 @@
|
||||
Anticipatory IO scheduler
|
||||
-------------------------
|
||||
Nick Piggin <piggin@cyberone.com.au> 13 Sep 2003
|
||||
|
||||
Attention! Database servers, especially those using "TCQ" disks should
|
||||
investigate performance with the 'deadline' IO scheduler. Any system with high
|
||||
disk performance requirements should do so, in fact.
|
||||
|
||||
If you see unusual performance characteristics of your disk systems, or you
|
||||
see big performance regressions versus the deadline scheduler, please email
|
||||
me. Database users don't bother unless you're willing to test a lot of patches
|
||||
from me ;) its a known issue.
|
||||
|
||||
Also, users with hardware RAID controllers, doing striping, may find
|
||||
highly variable performance results with using the as-iosched. The
|
||||
as-iosched anticipatory implementation is based on the notion that a disk
|
||||
device has only one physical seeking head. A striped RAID controller
|
||||
actually has a head for each physical device in the logical RAID device.
|
||||
|
||||
However, setting the antic_expire (see tunable parameters below) produces
|
||||
very similar behavior to the deadline IO scheduler.
|
||||
|
||||
Selecting IO schedulers
|
||||
-----------------------
|
||||
Refer to Documentation/block/switching-sched.txt for information on
|
||||
selecting an io scheduler on a per-device basis.
|
||||
|
||||
Anticipatory IO scheduler Policies
|
||||
----------------------------------
|
||||
The as-iosched implementation implements several layers of policies
|
||||
to determine when an IO request is dispatched to the disk controller.
|
||||
Here are the policies outlined, in order of application.
|
||||
|
||||
1. one-way Elevator algorithm.
|
||||
|
||||
The elevator algorithm is similar to that used in deadline scheduler, with
|
||||
the addition that it allows limited backward movement of the elevator
|
||||
(i.e. seeks backwards). A seek backwards can occur when choosing between
|
||||
two IO requests where one is behind the elevator's current position, and
|
||||
the other is in front of the elevator's position. If the seek distance to
|
||||
the request in back of the elevator is less than half the seek distance to
|
||||
the request in front of the elevator, then the request in back can be chosen.
|
||||
Backward seeks are also limited to a maximum of MAXBACK (1024*1024) sectors.
|
||||
This favors forward movement of the elevator, while allowing opportunistic
|
||||
"short" backward seeks.
|
||||
|
||||
2. FIFO expiration times for reads and for writes.
|
||||
|
||||
This is again very similar to the deadline IO scheduler. The expiration
|
||||
times for requests on these lists is tunable using the parameters read_expire
|
||||
and write_expire discussed below. When a read or a write expires in this way,
|
||||
the IO scheduler will interrupt its current elevator sweep or read anticipation
|
||||
to service the expired request.
|
||||
|
||||
3. Read and write request batching
|
||||
|
||||
A batch is a collection of read requests or a collection of write
|
||||
requests. The as scheduler alternates dispatching read and write batches
|
||||
to the driver. In the case a read batch, the scheduler submits read
|
||||
requests to the driver as long as there are read requests to submit, and
|
||||
the read batch time limit has not been exceeded (read_batch_expire).
|
||||
The read batch time limit begins counting down only when there are
|
||||
competing write requests pending.
|
||||
|
||||
In the case of a write batch, the scheduler submits write requests to
|
||||
the driver as long as there are write requests available, and the
|
||||
write batch time limit has not been exceeded (write_batch_expire).
|
||||
However, the length of write batches will be gradually shortened
|
||||
when read batches frequently exceed their time limit.
|
||||
|
||||
When changing between batch types, the scheduler waits for all requests
|
||||
from the previous batch to complete before scheduling requests for the
|
||||
next batch.
|
||||
|
||||
The read and write fifo expiration times described in policy 2 above
|
||||
are checked only when in scheduling IO of a batch for the corresponding
|
||||
(read/write) type. So for example, the read FIFO timeout values are
|
||||
tested only during read batches. Likewise, the write FIFO timeout
|
||||
values are tested only during write batches. For this reason,
|
||||
it is generally not recommended for the read batch time
|
||||
to be longer than the write expiration time, nor for the write batch
|
||||
time to exceed the read expiration time (see tunable parameters below).
|
||||
|
||||
When the IO scheduler changes from a read to a write batch,
|
||||
it begins the elevator from the request that is on the head of the
|
||||
write expiration FIFO. Likewise, when changing from a write batch to
|
||||
a read batch, scheduler begins the elevator from the first entry
|
||||
on the read expiration FIFO.
|
||||
|
||||
4. Read anticipation.
|
||||
|
||||
Read anticipation occurs only when scheduling a read batch.
|
||||
This implementation of read anticipation allows only one read request
|
||||
to be dispatched to the disk controller at a time. In
|
||||
contrast, many write requests may be dispatched to the disk controller
|
||||
at a time during a write batch. It is this characteristic that can make
|
||||
the anticipatory scheduler perform anomalously with controllers supporting
|
||||
TCQ, or with hardware striped RAID devices. Setting the antic_expire
|
||||
queue parameter (see below) to zero disables this behavior, and the
|
||||
anticipatory scheduler behaves essentially like the deadline scheduler.
|
||||
|
||||
When read anticipation is enabled (antic_expire is not zero), reads
|
||||
are dispatched to the disk controller one at a time.
|
||||
At the end of each read request, the IO scheduler examines its next
|
||||
candidate read request from its sorted read list. If that next request
|
||||
is from the same process as the request that just completed,
|
||||
or if the next request in the queue is "very close" to the
|
||||
just completed request, it is dispatched immediately. Otherwise,
|
||||
statistics (average think time, average seek distance) on the process
|
||||
that submitted the just completed request are examined. If it seems
|
||||
likely that that process will submit another request soon, and that
|
||||
request is likely to be near the just completed request, then the IO
|
||||
scheduler will stop dispatching more read requests for up to (antic_expire)
|
||||
milliseconds, hoping that process will submit a new request near the one
|
||||
that just completed. If such a request is made, then it is dispatched
|
||||
immediately. If the antic_expire wait time expires, then the IO scheduler
|
||||
will dispatch the next read request from the sorted read queue.
|
||||
|
||||
To decide whether an anticipatory wait is worthwhile, the scheduler
|
||||
maintains statistics for each process that can be used to compute
|
||||
mean "think time" (the time between read requests), and mean seek
|
||||
distance for that process. One observation is that these statistics
|
||||
are associated with each process, but those statistics are not associated
|
||||
with a specific IO device. So for example, if a process is doing IO
|
||||
on several file systems on separate devices, the statistics will be
|
||||
a combination of IO behavior from all those devices.
|
||||
|
||||
|
||||
Tuning the anticipatory IO scheduler
|
||||
------------------------------------
|
||||
When using 'as', the anticipatory IO scheduler there are 5 parameters under
|
||||
/sys/block/*/queue/iosched/. All are units of milliseconds.
|
||||
|
||||
The parameters are:
|
||||
* read_expire
|
||||
Controls how long until a read request becomes "expired". It also controls the
|
||||
interval between which expired requests are served, so set to 50, a request
|
||||
might take anywhere < 100ms to be serviced _if_ it is the next on the
|
||||
expired list. Obviously request expiration strategies won't make the disk
|
||||
go faster. The result basically equates to the timeslice a single reader
|
||||
gets in the presence of other IO. 100*((seek time / read_expire) + 1) is
|
||||
very roughly the % streaming read efficiency your disk should get with
|
||||
multiple readers.
|
||||
|
||||
* read_batch_expire
|
||||
Controls how much time a batch of reads is given before pending writes are
|
||||
served. A higher value is more efficient. This might be set below read_expire
|
||||
if writes are to be given higher priority than reads, but reads are to be
|
||||
as efficient as possible when there are no writes. Generally though, it
|
||||
should be some multiple of read_expire.
|
||||
|
||||
* write_expire, and
|
||||
* write_batch_expire are equivalent to the above, for writes.
|
||||
|
||||
* antic_expire
|
||||
Controls the maximum amount of time we can anticipate a good read (one
|
||||
with a short seek distance from the most recently completed request) before
|
||||
giving up. Many other factors may cause anticipation to be stopped early,
|
||||
or some processes will not be "anticipated" at all. Should be a bit higher
|
||||
for big seek time devices though not a linear correspondence - most
|
||||
processes have only a few ms thinktime.
|
||||
|
||||
In addition to the tunables above there is a read-only file named est_time
|
||||
which, when read, will show:
|
||||
|
||||
- The probability of a task exiting without a cooperating task
|
||||
submitting an anticipated IO.
|
||||
|
||||
- The current mean think time.
|
||||
|
||||
- The seek distance used to determine if an incoming IO is better.
|
||||
|
||||
@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
||||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to Documentation/DMA-mapping.txt for a discussion
|
||||
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
|
||||
@ -472,3 +472,52 @@ Why: These two features use non-standard interfaces. There are the
|
||||
Who: Corentin Chary <corentin.chary@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: usbvideo quickcam_messenger driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv06xx
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ov511 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ov511.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: w9968cf v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/w9968cf*.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ovcamchip sensor framework
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ovcamchip/*
|
||||
Why: Only used by obsoleted v4l1 drivers
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: stv680 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/stv680.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv0680
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: zc0301 v4l driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/zc0301/*
|
||||
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
|
||||
supports 2 USB-ID's (because it only supports a limited set of
|
||||
sensors) wich are also supported by the gspca_zc3xx driver
|
||||
(which supports 53 USB-ID's in total)
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
@ -196,7 +196,7 @@ nobarrier This also requires an IO stack which can support
|
||||
also be used to enable or disable barriers, for
|
||||
consistency with other ext4 mount options.
|
||||
|
||||
inode_readahead=n This tuning parameter controls the maximum
|
||||
inode_readahead_blks=n This tuning parameter controls the maximum
|
||||
number of inode table blocks that ext4's inode
|
||||
table readahead algorithm will pre-read into
|
||||
the buffer cache. The default value is 32 blocks.
|
||||
|
||||
@ -28,7 +28,7 @@ described in the man pages included in the package.
|
||||
Project web page: http://www.nilfs.org/en/
|
||||
Download page: http://www.nilfs.org/en/download.html
|
||||
Git tree web page: http://www.nilfs.org/git/
|
||||
NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users
|
||||
List info: http://vger.kernel.org/vger-lists.html#linux-nilfs
|
||||
|
||||
Caveats
|
||||
=======
|
||||
|
||||
@ -177,7 +177,6 @@ read the file /proc/PID/status:
|
||||
CapBnd: ffffffffffffffff
|
||||
voluntary_ctxt_switches: 0
|
||||
nonvoluntary_ctxt_switches: 1
|
||||
Stack usage: 12 kB
|
||||
|
||||
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
|
||||
@ -231,7 +230,6 @@ Table 1-2: Contents of the statm files (as of 2.6.30-rc7)
|
||||
Mems_allowed_list Same as previous, but in "list format"
|
||||
voluntary_ctxt_switches number of voluntary context switches
|
||||
nonvoluntary_ctxt_switches number of non voluntary context switches
|
||||
Stack usage: stack usage high water mark (round up to page size)
|
||||
..............................................................................
|
||||
|
||||
Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
|
||||
|
||||
102
Documentation/hwmon/amc6821
Normal file
102
Documentation/hwmon/amc6821
Normal file
@ -0,0 +1,102 @@
|
||||
Kernel driver amc6821
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments AMC6821
|
||||
Prefix: 'amc6821'
|
||||
Addresses scanned: 0x18, 0x19, 0x1a, 0x2c, 0x2d, 0x2e, 0x4c, 0x4d, 0x4e
|
||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/amc6821.html
|
||||
|
||||
Authors:
|
||||
Tomaz Mertelj <tomaz.mertelj@guest.arnes.si>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Texas Instruments amc6821 chip.
|
||||
The chip has one on-chip and one remote temperature sensor and one pwm fan
|
||||
regulator.
|
||||
The pwm can be controlled either from software or automatically.
|
||||
|
||||
The driver provides the following sensor accesses in sysfs:
|
||||
|
||||
temp1_input ro on-chip temperature
|
||||
temp1_min rw "
|
||||
temp1_max rw "
|
||||
temp1_crit rw "
|
||||
temp1_min_alarm ro "
|
||||
temp1_max_alarm ro "
|
||||
temp1_crit_alarm ro "
|
||||
|
||||
temp2_input ro remote temperature
|
||||
temp2_min rw "
|
||||
temp2_max rw "
|
||||
temp2_crit rw "
|
||||
temp2_min_alarm ro "
|
||||
temp2_max_alarm ro "
|
||||
temp2_crit_alarm ro "
|
||||
temp2_fault ro "
|
||||
|
||||
fan1_input ro tachometer speed
|
||||
fan1_min rw "
|
||||
fan1_max rw "
|
||||
fan1_fault ro "
|
||||
fan1_div rw Fan divisor can be either 2 or 4.
|
||||
|
||||
pwm1 rw pwm1
|
||||
pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled
|
||||
by remote temperature, 3=fan controlled by
|
||||
combination of the on-chip temperature and
|
||||
remote-sensor temperature,
|
||||
pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3
|
||||
pwm1_auto_point1_pwm ro Hardwired to 0, shared for both
|
||||
temperature channels.
|
||||
pwm1_auto_point2_pwm rw This value is shared for both temperature
|
||||
channels.
|
||||
pwm1_auto_point3_pwm rw Hardwired to 255, shared for both
|
||||
temperature channels.
|
||||
|
||||
temp1_auto_point1_temp ro Hardwired to temp2_auto_point1_temp
|
||||
which is rw. Below this temperature fan stops.
|
||||
temp1_auto_point2_temp rw The low-temperature limit of the proportional
|
||||
range. Below this temperature
|
||||
pwm1 = pwm1_auto_point2_pwm. It can go from
|
||||
0 degree C to 124 degree C in steps of
|
||||
4 degree C. Read it out after writing to get
|
||||
the actual value.
|
||||
temp1_auto_point3_temp rw Above this temperature fan runs at maximum
|
||||
speed. It can go from temp1_auto_point2_temp.
|
||||
It can only have certain discrete values
|
||||
which depend on temp1_auto_point2_temp and
|
||||
pwm1_auto_point2_pwm. Read it out after
|
||||
writing to get the actual value.
|
||||
|
||||
temp2_auto_point1_temp rw Must be between 0 degree C and 63 degree C and
|
||||
it defines the passive cooling temperature.
|
||||
Below this temperature the fan stops in
|
||||
the closed loop mode.
|
||||
temp2_auto_point2_temp rw The low-temperature limit of the proportional
|
||||
range. Below this temperature
|
||||
pwm1 = pwm1_auto_point2_pwm. It can go from
|
||||
0 degree C to 124 degree C in steps
|
||||
of 4 degree C.
|
||||
|
||||
temp2_auto_point3_temp rw Above this temperature fan runs at maximum
|
||||
speed. It can only have certain discrete
|
||||
values which depend on temp2_auto_point2_temp
|
||||
and pwm1_auto_point2_pwm. Read it out after
|
||||
writing to get actual value.
|
||||
|
||||
|
||||
Module parameters
|
||||
-----------------
|
||||
|
||||
If your board has a BIOS that initializes the amc6821 correctly, you should
|
||||
load the module with: init=0.
|
||||
|
||||
If your board BIOS doesn't initialize the chip, or you want
|
||||
different settings, you can set the following parameters:
|
||||
init=1,
|
||||
pwminv: 0 default pwm output, 1 inverts pwm output.
|
||||
|
||||
@ -3,8 +3,8 @@ Kernel driver k10temp
|
||||
|
||||
Supported chips:
|
||||
* AMD Family 10h processors:
|
||||
Socket F: Quad-Core/Six-Core/Embedded Opteron
|
||||
Socket AM2+: Opteron, Phenom (II) X3/X4
|
||||
Socket F: Quad-Core/Six-Core/Embedded Opteron (but see below)
|
||||
Socket AM2+: Quad-Core Opteron, Phenom (II) X3/X4, Athlon X2 (but see below)
|
||||
Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II
|
||||
Socket S1G3: Athlon II, Sempron, Turion II
|
||||
* AMD Family 11h processors:
|
||||
@ -36,10 +36,15 @@ Description
|
||||
This driver permits reading of the internal temperature sensor of AMD
|
||||
Family 10h and 11h processors.
|
||||
|
||||
All these processors have a sensor, but on older revisions of Family 10h
|
||||
processors, the sensor may return inconsistent values (erratum 319). The
|
||||
driver will refuse to load on these revisions unless you specify the
|
||||
"force=1" module parameter.
|
||||
All these processors have a sensor, but on those for Socket F or AM2+,
|
||||
the sensor may return inconsistent values (erratum 319). The driver
|
||||
will refuse to load on these revisions unless you specify the "force=1"
|
||||
module parameter.
|
||||
|
||||
Due to technical reasons, the driver can detect only the mainboard's
|
||||
socket type, not the processor's actual capabilities. Therefore, if you
|
||||
are using an AM3 processor on an AM2+ mainboard, you can safely use the
|
||||
"force=1" parameter.
|
||||
|
||||
There is one temperature measurement value, available as temp1_input in
|
||||
sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree.
|
||||
|
||||
@ -56,10 +56,11 @@ Following this convention is good because:
|
||||
(5) When following the convention, the driver code can use generic
|
||||
code to copy the parameters between user and kernel space.
|
||||
|
||||
This table lists ioctls visible from user land for Linux/i386. It contains
|
||||
most drivers up to 2.3.14, but I know I am missing some.
|
||||
This table lists ioctls visible from user land for Linux/x86. It contains
|
||||
most drivers up to 2.6.31, but I know I am missing some. There has been
|
||||
no attempt to list non-X86 architectures or ioctls from drivers/staging/.
|
||||
|
||||
Code Seq# Include File Comments
|
||||
Code Seq#(hex) Include File Comments
|
||||
========================================================
|
||||
0x00 00-1F linux/fs.h conflict!
|
||||
0x00 00-1F scsi/scsi_ioctl.h conflict!
|
||||
@ -69,119 +70,228 @@ Code Seq# Include File Comments
|
||||
0x03 all linux/hdreg.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
|
||||
0x09 all linux/raid/md_u.h
|
||||
0x10 00-0F drivers/char/s390/vmcp.h
|
||||
0x12 all linux/fs.h
|
||||
linux/blkpg.h
|
||||
0x1b all InfiniBand Subsystem <http://www.openib.org/>
|
||||
0x20 all drivers/cdrom/cm206.h
|
||||
0x22 all scsi/sg.h
|
||||
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
|
||||
'$' 00-0F linux/perf_counter.h, linux/perf_event.h
|
||||
'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl
|
||||
<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
|
||||
'2' 01-04 linux/i2o.h
|
||||
'3' 00-0F drivers/s390/char/raw3270.h conflict!
|
||||
'3' 00-1F linux/suspend_ioctls.h conflict!
|
||||
and kernel/power/user.c
|
||||
'8' all SNP8023 advanced NIC card
|
||||
<mailto:mcr@solidum.com>
|
||||
'A' 00-1F linux/apm_bios.h
|
||||
'@' 00-0F linux/radeonfb.h conflict!
|
||||
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
|
||||
'A' 00-1F linux/apm_bios.h conflict!
|
||||
'A' 00-0F linux/agpgart.h conflict!
|
||||
and drivers/char/agp/compat_ioctl.h
|
||||
'A' 00-7F sound/asound.h conflict!
|
||||
'B' 00-1F linux/cciss_ioctl.h conflict!
|
||||
'B' 00-0F include/linux/pmu.h conflict!
|
||||
'B' C0-FF advanced bbus
|
||||
<mailto:maassen@uni-freiburg.de>
|
||||
'C' all linux/soundcard.h
|
||||
'C' all linux/soundcard.h conflict!
|
||||
'C' 01-2F linux/capi.h conflict!
|
||||
'C' F0-FF drivers/net/wan/cosa.h conflict!
|
||||
'D' all arch/s390/include/asm/dasd.h
|
||||
'E' all linux/input.h
|
||||
'F' all linux/fb.h
|
||||
'H' all linux/hiddev.h
|
||||
'I' all linux/isdn.h
|
||||
'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h
|
||||
'D' 05 drivers/scsi/pmcraid.h
|
||||
'E' all linux/input.h conflict!
|
||||
'E' 00-0F xen/evtchn.h conflict!
|
||||
'F' all linux/fb.h conflict!
|
||||
'F' 01-02 drivers/scsi/pmcraid.h conflict!
|
||||
'F' 20 drivers/video/fsl-diu-fb.h conflict!
|
||||
'F' 20 drivers/video/intelfb/intelfb.h conflict!
|
||||
'F' 20 linux/ivtvfb.h conflict!
|
||||
'F' 20 linux/matroxfb.h conflict!
|
||||
'F' 20 drivers/video/aty/atyfb_base.c conflict!
|
||||
'F' 00-0F video/da8xx-fb.h conflict!
|
||||
'F' 80-8F linux/arcfb.h conflict!
|
||||
'F' DD video/sstfb.h conflict!
|
||||
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
|
||||
'G' 00-0F linux/gigaset_dev.h conflict!
|
||||
'H' 00-7F linux/hiddev.h conflict!
|
||||
'H' 00-0F linux/hidraw.h conflict!
|
||||
'H' 00-0F sound/asound.h conflict!
|
||||
'H' 20-40 sound/asound_fm.h conflict!
|
||||
'H' 80-8F sound/sfnt_info.h conflict!
|
||||
'H' 10-8F sound/emu10k1.h conflict!
|
||||
'H' 10-1F sound/sb16_csp.h conflict!
|
||||
'H' 10-1F sound/hda_hwdep.h conflict!
|
||||
'H' 40-4F sound/hdspm.h conflict!
|
||||
'H' 40-4F sound/hdsp.h conflict!
|
||||
'H' 90 sound/usb/usx2y/usb_stream.h
|
||||
'H' C0-F0 net/bluetooth/hci.h conflict!
|
||||
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
|
||||
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
|
||||
'H' C0-DF net/bluetooth/bnep/bnep.h conflict!
|
||||
'I' all linux/isdn.h conflict!
|
||||
'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict!
|
||||
'I' 40-4F linux/mISDNif.h conflict!
|
||||
'J' 00-1F drivers/scsi/gdth_ioctl.h
|
||||
'K' all linux/kd.h
|
||||
'L' 00-1F linux/loop.h
|
||||
'L' 20-2F driver/usb/misc/vstusb.h
|
||||
'L' 00-1F linux/loop.h conflict!
|
||||
'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict!
|
||||
'L' 20-2F linux/usb/vstusb.h
|
||||
'L' E0-FF linux/ppdd.h encrypted disk device driver
|
||||
<http://linux01.gwdg.de/~alatham/ppdd.html>
|
||||
'M' all linux/soundcard.h
|
||||
'M' all linux/soundcard.h conflict!
|
||||
'M' 01-16 mtd/mtd-abi.h conflict!
|
||||
and drivers/mtd/mtdchar.c
|
||||
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
|
||||
'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
|
||||
'N' 00-1F drivers/usb/scanner.h
|
||||
'O' 00-02 include/mtd/ubi-user.h UBI
|
||||
'P' all linux/soundcard.h
|
||||
'O' 00-06 mtd/ubi-user.h UBI
|
||||
'P' all linux/soundcard.h conflict!
|
||||
'P' 60-6F sound/sscape_ioctl.h conflict!
|
||||
'P' 00-0F drivers/usb/class/usblp.c conflict!
|
||||
'Q' all linux/soundcard.h
|
||||
'R' 00-1F linux/random.h
|
||||
'R' 00-1F linux/random.h conflict!
|
||||
'R' 01 linux/rfkill.h conflict!
|
||||
'R' 01-0F media/rds.h conflict!
|
||||
'R' C0-DF net/bluetooth/rfcomm.h
|
||||
'S' all linux/cdrom.h conflict!
|
||||
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
||||
'S' 82-FF scsi/scsi.h conflict!
|
||||
'S' 00-7F sound/asequencer.h conflict!
|
||||
'T' all linux/soundcard.h conflict!
|
||||
'T' 00-AF sound/asound.h conflict!
|
||||
'T' all arch/x86/include/asm/ioctls.h conflict!
|
||||
'U' 00-EF linux/drivers/usb/usb.h
|
||||
'V' all linux/vt.h
|
||||
'T' C0-DF linux/if_tun.h conflict!
|
||||
'U' all sound/asound.h conflict!
|
||||
'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict!
|
||||
'U' 00-CF linux/uinput.h conflict!
|
||||
'U' 00-EF linux/usbdevice_fs.h
|
||||
'U' C0-CF drivers/bluetooth/hci_uart.h
|
||||
'V' all linux/vt.h conflict!
|
||||
'V' all linux/videodev2.h conflict!
|
||||
'V' C0 linux/ivtvfb.h conflict!
|
||||
'V' C0 linux/ivtv.h conflict!
|
||||
'V' C0 media/davinci/vpfe_capture.h conflict!
|
||||
'V' C0 media/si4713.h conflict!
|
||||
'V' C0-CF drivers/media/video/mxb.h conflict!
|
||||
'W' 00-1F linux/watchdog.h conflict!
|
||||
'W' 00-1F linux/wanrouter.h conflict!
|
||||
'X' all linux/xfs_fs.h
|
||||
'W' 00-3F sound/asound.h conflict!
|
||||
'X' all fs/xfs/xfs_fs.h conflict!
|
||||
and fs/xfs/linux-2.6/xfs_ioctl32.h
|
||||
and include/linux/falloc.h
|
||||
and linux/fs.h
|
||||
'X' all fs/ocfs2/ocfs_fs.h conflict!
|
||||
'X' 01 linux/pktcdvd.h conflict!
|
||||
'Y' all linux/cyclades.h
|
||||
'[' 00-07 linux/usb/usbtmc.h USB Test and Measurement Devices
|
||||
'Z' 14-15 drivers/message/fusion/mptctl.h
|
||||
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
|
||||
<mailto:gregkh@suse.de>
|
||||
'a' all ATM on linux
|
||||
'a' all linux/atm*.h, linux/sonet.h ATM on linux
|
||||
<http://lrcwww.epfl.ch/linux-atm/magic.html>
|
||||
'b' 00-FF bit3 vme host bridge
|
||||
'b' 00-FF conflict! bit3 vme host bridge
|
||||
<mailto:natalia@nikhefk.nikhef.nl>
|
||||
'b' 00-0F media/bt819.h conflict!
|
||||
'c' all linux/cm4000_cs.h conflict!
|
||||
'c' 00-7F linux/comstats.h conflict!
|
||||
'c' 00-7F linux/coda.h conflict!
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h
|
||||
'c' A0-AF arch/x86/include/asm/msr.h
|
||||
'c' 00-1F linux/chio.h conflict!
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h conflict!
|
||||
'c' A0-AF arch/x86/include/asm/msr.h conflict!
|
||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||
'd' 02-40 pcmcia/ds.h conflict!
|
||||
'd' 10-3F drivers/media/video/dabusb.h conflict!
|
||||
'd' C0-CF drivers/media/video/saa7191.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
'e' all linux/digi1.h conflict!
|
||||
'e' 00-1F net/irda/irtty.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h
|
||||
'h' 00-7F Charon filesystem
|
||||
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h conflict!
|
||||
'f' 00-1F linux/ext3_fs.h conflict!
|
||||
'f' 00-0F fs/jfs/jfs_dinode.h conflict!
|
||||
'f' 00-0F fs/ext4/ext4.h conflict!
|
||||
'f' 00-0F linux/fs.h conflict!
|
||||
'f' 00-0F fs/ocfs2/ocfs2_fs.h conflict!
|
||||
'g' 00-0F linux/usb/gadgetfs.h
|
||||
'g' 20-2F linux/usb/g_printer.h
|
||||
'h' 00-7F conflict! Charon filesystem
|
||||
<mailto:zapman@interlan.net>
|
||||
'i' 00-3F linux/i2o.h
|
||||
'h' 00-1F linux/hpet.h conflict!
|
||||
'i' 00-3F linux/i2o-dev.h conflict!
|
||||
'i' 0B-1F linux/ipmi.h conflict!
|
||||
'i' 80-8F linux/i8k.h
|
||||
'j' 00-3F linux/joystick.h
|
||||
'k' 00-0F linux/spi/spidev.h conflict!
|
||||
'k' 00-05 video/kyro.h conflict!
|
||||
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||
<http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
<http://sourceforge.net/projects/linux-udf/>
|
||||
'm' 00-09 linux/mmtimer.h
|
||||
'm' 00-09 linux/mmtimer.h conflict!
|
||||
'm' all linux/mtio.h conflict!
|
||||
'm' all linux/soundcard.h conflict!
|
||||
'm' all linux/synclink.h conflict!
|
||||
'm' 00-19 drivers/message/fusion/mptctl.h conflict!
|
||||
'm' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict!
|
||||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h
|
||||
'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c
|
||||
'n' 80-8F linux/nilfs2_fs.h NILFS2
|
||||
'n' E0-FF video/matrox.h matroxfb
|
||||
'n' E0-FF linux/matroxfb.h matroxfb
|
||||
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
||||
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
'o' 40-41 include/mtd/ubi-user.h UBI
|
||||
'o' 01-A1 include/linux/dvb/*.h DVB
|
||||
'o' 00-03 mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
'o' 40-41 mtd/ubi-user.h UBI
|
||||
'o' 01-A1 linux/dvb/*.h DVB
|
||||
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
|
||||
'p' 00-1F linux/rtc.h conflict!
|
||||
'p' 00-3F linux/mc146818rtc.h conflict!
|
||||
'p' 40-7F linux/nvram.h
|
||||
'p' 80-9F user-space parport
|
||||
'p' 80-9F linux/ppdev.h user-space parport
|
||||
<mailto:tim@cyberelk.net>
|
||||
'p' a1-a4 linux/pps.h LinuxPPS
|
||||
'p' A1-A4 linux/pps.h LinuxPPS
|
||||
<mailto:giometti@linux.it>
|
||||
'q' 00-1F linux/serio.h
|
||||
'q' 80-FF Internet PhoneJACK, Internet LineJACK
|
||||
<http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h
|
||||
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
|
||||
linux/ixjuser.h <http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
|
||||
's' all linux/cdk.h
|
||||
't' 00-7F linux/if_ppp.h
|
||||
't' 80-8F linux/isdn_ppp.h
|
||||
't' 90 linux/toshiba.h
|
||||
'u' 00-1F linux/smb_fs.h
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' all linux/videodev.h conflict!
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
'v' 00-0F linux/sonypi.h conflict!
|
||||
'v' C0-CF drivers/media/video/ov511.h conflict!
|
||||
'v' C0-DF media/pwc-ioctl.h conflict!
|
||||
'v' C0-FF linux/meye.h conflict!
|
||||
'v' C0-CF drivers/media/video/zoran/zoran.h conflict!
|
||||
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
|
||||
'w' all CERN SCI driver
|
||||
'y' 00-1F packet based user level communications
|
||||
<mailto:zapman@interlan.net>
|
||||
'z' 00-3F CAN bus card
|
||||
'z' 00-3F CAN bus card conflict!
|
||||
<mailto:hdstich@connectu.ulm.circular.de>
|
||||
'z' 40-7F CAN bus card
|
||||
'z' 40-7F CAN bus card conflict!
|
||||
<mailto:oe@port.de>
|
||||
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
||||
0x80 00-1F linux/fb.h
|
||||
0x81 00-1F linux/videotext.h
|
||||
0x88 00-3F media/ovcamchip.h
|
||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||
0x89 0B-DF linux/sockios.h
|
||||
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
||||
0x89 E0-EF linux/dn.h PROTOPRIVATE range
|
||||
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
||||
0x8B all linux/wireless.h
|
||||
0x8C 00-3F WiNRADiO driver
|
||||
<http://www.proximity.com.au/~brian/winradio/>
|
||||
0x90 00 drivers/cdrom/sbpcd.h
|
||||
0x92 00-0F drivers/usb/mon/mon_bin.c
|
||||
0x93 60-7F linux/auto_fs.h
|
||||
0x94 all fs/btrfs/ioctl.h
|
||||
0x99 00-0F 537-Addinboard driver
|
||||
<mailto:buk@buks.ipn.de>
|
||||
0xA0 all linux/sdp/sdp.h Industrial Device Project
|
||||
@ -192,17 +302,22 @@ Code Seq# Include File Comments
|
||||
0xAB 00-1F linux/nbd.h
|
||||
0xAC 00-1F linux/raw.h
|
||||
0xAD 00 Netfilter device in development:
|
||||
<mailto:rusty@rustcorp.com.au>
|
||||
<mailto:rusty@rustcorp.com.au>
|
||||
0xAE all linux/kvm.h Kernel-based Virtual Machine
|
||||
<mailto:kvm@vger.kernel.org>
|
||||
0xB0 all RATIO devices in development:
|
||||
<mailto:vgo@ratio.de>
|
||||
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
|
||||
0xC0 00-0F linux/usb/iowarrior.h
|
||||
0xCB 00-1F CBM serial IEC bus in development:
|
||||
<mailto:michael.klein@puffin.lb.shuttle.de>
|
||||
0xCD 01 linux/reiserfs_fs.h
|
||||
0xCF 02 fs/cifs/ioctl.c
|
||||
0xDB 00-0F drivers/char/mwave/mwavepub.h
|
||||
0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
|
||||
<mailto:aherrman@de.ibm.com>
|
||||
0xF3 00-3F video/sisfb.h sisfb (in development)
|
||||
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
|
||||
<mailto:thomas@winischhofer.net>
|
||||
0xF4 00-1F video/mbxfb.h mbxfb
|
||||
<mailto:raph@8d.com>
|
||||
0xFD all linux/dm-ioctl.h
|
||||
|
||||
@ -149,10 +149,11 @@ char *(*procinfo)(struct capi_ctr *ctrlr)
|
||||
pointer to a callback function returning the entry for the device in
|
||||
the CAPI controller info table, /proc/capi/controller
|
||||
|
||||
read_proc_t *ctr_read_proc
|
||||
pointer to the read_proc callback function for the device's proc file
|
||||
system entry, /proc/capi/controllers/<n>; will be called with a
|
||||
pointer to the device's capi_ctr structure as the last (data) argument
|
||||
const struct file_operations *proc_fops
|
||||
pointers to callback functions for the device's proc file
|
||||
system entry, /proc/capi/controllers/<n>; pointer to the device's
|
||||
capi_ctr structure is available from struct proc_dir_entry::data
|
||||
which is available from struct inode.
|
||||
|
||||
Note: Callback functions except send_message() are never called in interrupt
|
||||
context.
|
||||
|
||||
@ -214,11 +214,13 @@ The format of the block comment is like this:
|
||||
* (section header: (section description)? )*
|
||||
(*)?*/
|
||||
|
||||
The short function description ***cannot be multiline***, but the other
|
||||
descriptions can be (and they can contain blank lines). If you continue
|
||||
that initial short description onto a second line, that second line will
|
||||
appear further down at the beginning of the description section, which is
|
||||
almost certainly not what you had in mind.
|
||||
All "description" text can span multiple lines, although the
|
||||
function_name & its short description are traditionally on a single line.
|
||||
Description text may also contain blank lines (i.e., lines that contain
|
||||
only a "*").
|
||||
|
||||
"section header:" names must be unique per function (or struct,
|
||||
union, typedef, enum).
|
||||
|
||||
Avoid putting a spurious blank line after the function name, or else the
|
||||
description will be repeated!
|
||||
|
||||
@ -54,6 +54,7 @@ parameter is applicable:
|
||||
IMA Integrity measurement architecture is enabled.
|
||||
IOSCHED More than one I/O scheduler is enabled.
|
||||
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
|
||||
IPV6 IPv6 support is enabled.
|
||||
ISAPNP ISA PnP code is enabled.
|
||||
ISDN Appropriate ISDN support is enabled.
|
||||
JOY Appropriate joystick support is enabled.
|
||||
@ -240,7 +241,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
acpi_sleep= [HW,ACPI] Sleep options
|
||||
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
|
||||
old_ordering, s4_nonvs }
|
||||
old_ordering, s4_nonvs, sci_force_enable }
|
||||
See Documentation/power/video.txt for information on
|
||||
s3_bios and s3_mode.
|
||||
s3_beep is for debugging; it makes the PC's speaker beep
|
||||
@ -253,6 +254,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
of _PTS is used by default).
|
||||
s4_nonvs prevents the kernel from saving/restoring the
|
||||
ACPI NVS memory during hibernation.
|
||||
sci_force_enable causes the kernel to set SCI_EN directly
|
||||
on resume from S1/S3 (which is against the ACPI spec,
|
||||
but some broken systems don't work without it).
|
||||
|
||||
acpi_use_timer_override [HW,ACPI]
|
||||
Use timer override. For some broken Nvidia NF5 boards
|
||||
@ -344,6 +348,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Change the amount of debugging information output
|
||||
when initialising the APIC and IO-APIC components.
|
||||
|
||||
autoconf= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
|
||||
show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
|
||||
Limit apic dumping. The parameter defines the maximal
|
||||
number of local apics being dumped. Also it is possible
|
||||
@ -626,6 +633,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
See drivers/char/README.epca and
|
||||
Documentation/serial/digiepca.txt.
|
||||
|
||||
disable= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
|
||||
disable_ipv6= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
|
||||
disable_mtrr_cleanup [X86]
|
||||
The kernel tries to adjust MTRR layout from continuous
|
||||
to discrete, to make X server driver able to add WB
|
||||
|
||||
@ -685,7 +685,7 @@ struct kvm_vcpu_events {
|
||||
__u8 pad;
|
||||
} nmi;
|
||||
__u32 sipi_vector;
|
||||
__u32 flags; /* must be zero */
|
||||
__u32 flags;
|
||||
};
|
||||
|
||||
4.30 KVM_SET_VCPU_EVENTS
|
||||
@ -701,6 +701,14 @@ vcpu.
|
||||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
Fields that may be modified asynchronously by running VCPUs can be excluded
|
||||
from the update. These fields are nmi.pending and sipi_vector. Keep the
|
||||
corresponding bits in the flags field cleared to suppress overwriting the
|
||||
current in-kernel state. The bits are:
|
||||
|
||||
KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
|
||||
KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
|
||||
|
||||
|
||||
5. The kvm_run structure
|
||||
|
||||
|
||||
@ -1092,8 +1092,8 @@ WARNING:
|
||||
its level up and down at every change.
|
||||
|
||||
|
||||
Volume control
|
||||
--------------
|
||||
Volume control (Console Audio control)
|
||||
--------------------------------------
|
||||
|
||||
procfs: /proc/acpi/ibm/volume
|
||||
ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC"
|
||||
@ -1110,9 +1110,53 @@ the desktop environment to just provide on-screen-display feedback.
|
||||
Software volume control should be done only in the main AC97/HDA
|
||||
mixer.
|
||||
|
||||
This feature allows volume control on ThinkPad models with a digital
|
||||
volume knob (when available, not all models have it), as well as
|
||||
mute/unmute control. The available commands are:
|
||||
|
||||
About the ThinkPad Console Audio control:
|
||||
|
||||
ThinkPads have a built-in amplifier and muting circuit that drives the
|
||||
console headphone and speakers. This circuit is after the main AC97
|
||||
or HDA mixer in the audio path, and under exclusive control of the
|
||||
firmware.
|
||||
|
||||
ThinkPads have three special hotkeys to interact with the console
|
||||
audio control: volume up, volume down and mute.
|
||||
|
||||
It is worth noting that the normal way the mute function works (on
|
||||
ThinkPads that do not have a "mute LED") is:
|
||||
|
||||
1. Press mute to mute. It will *always* mute, you can press it as
|
||||
many times as you want, and the sound will remain mute.
|
||||
|
||||
2. Press either volume key to unmute the ThinkPad (it will _not_
|
||||
change the volume, it will just unmute).
|
||||
|
||||
This is a very superior design when compared to the cheap software-only
|
||||
mute-toggle solution found on normal consumer laptops: you can be
|
||||
absolutely sure the ThinkPad will not make noise if you press the mute
|
||||
button, no matter the previous state.
|
||||
|
||||
The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain
|
||||
amplifiers driving the speakers and headphone output, and the firmware
|
||||
also handles volume control for the headphone and speakers on these
|
||||
ThinkPads without any help from the operating system (this volume
|
||||
control stage exists after the main AC97 or HDA mixer in the audio
|
||||
path).
|
||||
|
||||
The newer Lenovo models only have firmware mute control, and depend on
|
||||
the main HDA mixer to do volume control (which is done by the operating
|
||||
system). In this case, the volume keys are filtered out for unmute
|
||||
key press (there are some firmware bugs in this area) and delivered as
|
||||
normal key presses to the operating system (thinkpad-acpi is not
|
||||
involved).
|
||||
|
||||
|
||||
The ThinkPad-ACPI volume control:
|
||||
|
||||
The preferred way to interact with the Console Audio control is the
|
||||
ALSA interface.
|
||||
|
||||
The legacy procfs interface allows one to read the current state,
|
||||
and if volume control is enabled, accepts the following commands:
|
||||
|
||||
echo up >/proc/acpi/ibm/volume
|
||||
echo down >/proc/acpi/ibm/volume
|
||||
@ -1121,12 +1165,10 @@ mute/unmute control. The available commands are:
|
||||
echo 'level <level>' >/proc/acpi/ibm/volume
|
||||
|
||||
The <level> number range is 0 to 14 although not all of them may be
|
||||
distinct. The unmute the volume after the mute command, use either the
|
||||
distinct. To unmute the volume after the mute command, use either the
|
||||
up or down command (the level command will not unmute the volume), or
|
||||
the unmute command.
|
||||
|
||||
The current volume level and mute state is shown in the file.
|
||||
|
||||
You can use the volume_capabilities parameter to tell the driver
|
||||
whether your thinkpad has volume control or mute-only control:
|
||||
volume_capabilities=1 for mixers with mute and volume control,
|
||||
|
||||
@ -48,11 +48,11 @@ for LILO parameters for doing this:
|
||||
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
|
||||
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
|
||||
with other card types when overriding the I/O address. When the driver is
|
||||
loaded as a module, only the IRQ and transceiver setting may be overridden.
|
||||
For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using
|
||||
the xcvr and irq module options:
|
||||
loaded as a module, only the IRQ may be overridden. For example,
|
||||
setting two cards to IRQ10 and IRQ11 is done by using the irq module
|
||||
option:
|
||||
|
||||
options 3c509 xcvr=3,1 irq=10,11
|
||||
options 3c509 irq=10,11
|
||||
|
||||
|
||||
(2) Full-duplex mode
|
||||
@ -77,6 +77,8 @@ operation.
|
||||
itself full-duplex capable. This is almost certainly one of two things: a full-
|
||||
duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
|
||||
another system that's connected directly to the 3c509B via a crossover cable.
|
||||
|
||||
Full-duplex mode can be enabled using 'ethtool'.
|
||||
|
||||
/////Extremely important caution concerning full-duplex mode/////
|
||||
Understand that the 3c509B's hardware's full-duplex support is much more
|
||||
@ -113,6 +115,8 @@ This insured that merely upgrading the driver from an earlier version would
|
||||
never automatically enable full-duplex mode in an existing installation;
|
||||
it must always be explicitly enabled via one of these code in order to be
|
||||
activated.
|
||||
|
||||
The transceiver type can be changed using 'ethtool'.
|
||||
|
||||
|
||||
(4a) Interpretation of error messages and common problems
|
||||
|
||||
@ -692,6 +692,25 @@ proxy_arp - BOOLEAN
|
||||
conf/{all,interface}/proxy_arp is set to TRUE,
|
||||
it will be disabled otherwise
|
||||
|
||||
proxy_arp_pvlan - BOOLEAN
|
||||
Private VLAN proxy arp.
|
||||
Basically allow proxy arp replies back to the same interface
|
||||
(from which the ARP request/solicitation was received).
|
||||
|
||||
This is done to support (ethernet) switch features, like RFC
|
||||
3069, where the individual ports are NOT allowed to
|
||||
communicate with each other, but they are allowed to talk to
|
||||
the upstream router. As described in RFC 3069, it is possible
|
||||
to allow these hosts to communicate through the upstream
|
||||
router by proxy_arp'ing. Don't need to be used together with
|
||||
proxy_arp.
|
||||
|
||||
This technology is known by different names:
|
||||
In RFC 3069 it is called VLAN Aggregation.
|
||||
Cisco and Allied Telesyn call it Private VLAN.
|
||||
Hewlett-Packard call it Source-Port filtering or port-isolation.
|
||||
Ericsson call it MAC-Forced Forwarding (RFC Draft).
|
||||
|
||||
shared_media - BOOLEAN
|
||||
Send(router) or accept(host) RFC1620 shared media redirects.
|
||||
Overrides ip_secure_redirects.
|
||||
@ -833,9 +852,18 @@ arp_notify - BOOLEAN
|
||||
or hardware address changes.
|
||||
|
||||
arp_accept - BOOLEAN
|
||||
Define behavior when gratuitous arp replies are received:
|
||||
0 - drop gratuitous arp frames
|
||||
1 - accept gratuitous arp frames
|
||||
Define behavior for gratuitous ARP frames who's IP is not
|
||||
already present in the ARP table:
|
||||
0 - don't create new entries in the ARP table
|
||||
1 - create new entries in the ARP table
|
||||
|
||||
Both replies and requests type gratuitous arp will trigger the
|
||||
ARP table to be updated, if this setting is on.
|
||||
|
||||
If the ARP table already contains the IP address of the
|
||||
gratuitous arp frame, the arp table will be updated regardless
|
||||
if this setting is on or off.
|
||||
|
||||
|
||||
app_solicit - INTEGER
|
||||
The maximum number of probes to send to the user space ARP daemon
|
||||
|
||||
90
Documentation/networking/ixgbevf.txt
Executable file
90
Documentation/networking/ixgbevf.txt
Executable file
@ -0,0 +1,90 @@
|
||||
Linux* Base Driver for Intel(R) Network Connection
|
||||
==================================================
|
||||
|
||||
November 24, 2009
|
||||
|
||||
Contents
|
||||
========
|
||||
|
||||
- In This Release
|
||||
- Identifying Your Adapter
|
||||
- Known Issues/Troubleshooting
|
||||
- Support
|
||||
|
||||
In This Release
|
||||
===============
|
||||
|
||||
This file describes the ixgbevf Linux* Base Driver for Intel Network
|
||||
Connection.
|
||||
|
||||
The ixgbevf driver supports 82599-based virtual function devices that can only
|
||||
be activated on kernels with CONFIG_PCI_IOV enabled.
|
||||
|
||||
The ixgbevf driver supports virtual functions generated by the ixgbe driver
|
||||
with a max_vfs value of 1 or greater.
|
||||
|
||||
The guest OS loading the ixgbevf driver must support MSI-X interrupts.
|
||||
|
||||
VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
|
||||
|
||||
Identifying Your Adapter
|
||||
========================
|
||||
|
||||
For more information on how to identify your adapter, go to the Adapter &
|
||||
Driver ID Guide at:
|
||||
|
||||
http://support.intel.com/support/network/sb/CS-008441.htm
|
||||
|
||||
Known Issues/Troubleshooting
|
||||
============================
|
||||
|
||||
Unloading Physical Function (PF) Driver Causes System Reboots When VM is
|
||||
Running and VF is Loaded on the VM
|
||||
------------------------------------------------------------------------
|
||||
Do not unload the PF driver (ixgbe) while VFs are assigned to guests.
|
||||
|
||||
Support
|
||||
=======
|
||||
|
||||
For general information, go to the Intel support website at:
|
||||
|
||||
http://support.intel.com
|
||||
|
||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
||||
|
||||
http://sourceforge.net/projects/e1000
|
||||
|
||||
If an issue is identified with the released source code on the supported
|
||||
kernel with a supported adapter, email the specific information related
|
||||
to the issue to e1000-devel@lists.sf.net
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
Intel 10 Gigabit Linux driver.
|
||||
Copyright(c) 1999 - 2009 Intel Corporation.
|
||||
|
||||
This program is free software; you can redistribute it and/or modify it
|
||||
under the terms and conditions of the GNU General Public License,
|
||||
version 2, as published by the Free Software Foundation.
|
||||
|
||||
This program is distributed in the hope it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
||||
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
||||
more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License along with
|
||||
this program; if not, write to the Free Software Foundation, Inc.,
|
||||
51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
|
||||
The full GNU General Public License is included in this distribution in
|
||||
the file called "COPYING".
|
||||
|
||||
Trademarks
|
||||
==========
|
||||
|
||||
Intel, Itanium, and Pentium are trademarks or registered trademarks of
|
||||
Intel Corporation or its subsidiaries in the United States and other
|
||||
countries.
|
||||
|
||||
* Other names and brands may be claimed as the property of others.
|
||||
@ -2,7 +2,7 @@
|
||||
+ ABSTRACT
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
This file documents the CONFIG_PACKET_MMAP option available with the PACKET
|
||||
This file documents the mmap() facility available with the PACKET
|
||||
socket interface on 2.4 and 2.6 kernels. This type of sockets is used for
|
||||
capture network traffic with utilities like tcpdump or any other that needs
|
||||
raw access to network interface.
|
||||
@ -44,7 +44,7 @@ enabled. For transmission, check the MTU (Maximum Transmission Unit) used and
|
||||
supported by devices of your network.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
+ How to use CONFIG_PACKET_MMAP to improve capture process
|
||||
+ How to use mmap() to improve capture process
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
From the user standpoint, you should use the higher level libpcap library, which
|
||||
@ -64,7 +64,7 @@ the low level details or want to improve libpcap by including PACKET_MMAP
|
||||
support.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
+ How to use CONFIG_PACKET_MMAP directly to improve capture process
|
||||
+ How to use mmap() directly to improve capture process
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
From the system calls stand point, the use of PACKET_MMAP involves
|
||||
@ -105,7 +105,7 @@ also the mapping of the circular buffer in the user process and
|
||||
the use of this buffer.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
+ How to use CONFIG_PACKET_MMAP directly to improve transmission process
|
||||
+ How to use mmap() directly to improve transmission process
|
||||
--------------------------------------------------------------------------------
|
||||
Transmission process is similar to capture as shown below.
|
||||
|
||||
|
||||
53
Documentation/powerpc/dts-bindings/fsl/can.txt
Normal file
53
Documentation/powerpc/dts-bindings/fsl/can.txt
Normal file
@ -0,0 +1,53 @@
|
||||
CAN Device Tree Bindings
|
||||
------------------------
|
||||
|
||||
(c) 2006-2009 Secret Lab Technologies Ltd
|
||||
Grant Likely <grant.likely@secretlab.ca>
|
||||
|
||||
fsl,mpc5200-mscan nodes
|
||||
-----------------------
|
||||
In addition to the required compatible-, reg- and interrupt-properties, you can
|
||||
also specify which clock source shall be used for the controller:
|
||||
|
||||
- fsl,mscan-clock-source : a string describing the clock source. Valid values
|
||||
are: "ip" for ip bus clock
|
||||
"ref" for reference clock (XTAL)
|
||||
"ref" is default in case this property is not
|
||||
present.
|
||||
|
||||
fsl,mpc5121-mscan nodes
|
||||
-----------------------
|
||||
In addition to the required compatible-, reg- and interrupt-properties, you can
|
||||
also specify which clock source and divider shall be used for the controller:
|
||||
|
||||
- fsl,mscan-clock-source : a string describing the clock source. Valid values
|
||||
are: "ip" for ip bus clock
|
||||
"ref" for reference clock
|
||||
"sys" for system clock
|
||||
If this property is not present, an optimal CAN
|
||||
clock source and frequency based on the system
|
||||
clock will be selected. If this is not possible,
|
||||
the reference clock will be used.
|
||||
|
||||
- fsl,mscan-clock-divider: for the reference and system clock, an additional
|
||||
clock divider can be specified. By default, a
|
||||
value of 1 is used.
|
||||
|
||||
Note that the MPC5121 Rev. 1 processor is not supported.
|
||||
|
||||
Examples:
|
||||
can@1300 {
|
||||
compatible = "fsl,mpc5121-mscan";
|
||||
interrupts = <12 0x8>;
|
||||
interrupt-parent = <&ipic>;
|
||||
reg = <0x1300 0x80>;
|
||||
};
|
||||
|
||||
can@1380 {
|
||||
compatible = "fsl,mpc5121-mscan";
|
||||
interrupts = <13 0x8>;
|
||||
interrupt-parent = <&ipic>;
|
||||
reg = <0x1380 0x80>;
|
||||
fsl,mscan-clock-source = "ref";
|
||||
fsl,mscan-clock-divider = <3>;
|
||||
};
|
||||
@ -195,11 +195,4 @@ External interrupts:
|
||||
|
||||
fsl,mpc5200-mscan nodes
|
||||
-----------------------
|
||||
In addition to the required compatible-, reg- and interrupt-properites, you can
|
||||
also specify which clock source shall be used for the controller:
|
||||
|
||||
- fsl,mscan-clock-source- a string describing the clock source. Valid values
|
||||
are: "ip" for ip bus clock
|
||||
"ref" for reference clock (XTAL)
|
||||
"ref" is default in case this property is not
|
||||
present.
|
||||
See file can.txt in this directory.
|
||||
|
||||
@ -95,7 +95,7 @@ card*/pcm*/xrun_debug
|
||||
It takes an integer value, can be changed by writing to this
|
||||
file, such as
|
||||
|
||||
# cat 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
# echo 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
|
||||
The value consists of the following bit flags:
|
||||
bit 0 = Enable XRUN/jiffies debug messages
|
||||
|
||||
@ -53,14 +53,14 @@ size of the mcount call that is embedded in the function).
|
||||
For example, if the function foo() calls bar(), when the bar() function calls
|
||||
mcount(), the arguments mcount() will pass to the tracer are:
|
||||
"frompc" - the address bar() will use to return to foo()
|
||||
"selfpc" - the address bar() (with _mcount() size adjustment)
|
||||
"selfpc" - the address bar() (with mcount() size adjustment)
|
||||
|
||||
Also keep in mind that this mcount function will be called *a lot*, so
|
||||
optimizing for the default case of no tracer will help the smooth running of
|
||||
your system when tracing is disabled. So the start of the mcount function is
|
||||
typically the bare min with checking things before returning. That also means
|
||||
the code flow should usually kept linear (i.e. no branching in the nop case).
|
||||
This is of course an optimization and not a hard requirement.
|
||||
typically the bare minimum with checking things before returning. That also
|
||||
means the code flow should usually be kept linear (i.e. no branching in the nop
|
||||
case). This is of course an optimization and not a hard requirement.
|
||||
|
||||
Here is some pseudo code that should help (these functions should actually be
|
||||
implemented in assembly):
|
||||
@ -131,10 +131,10 @@ some functions to save (hijack) and restore the return address.
|
||||
|
||||
The mcount function should check the function pointers ftrace_graph_return
|
||||
(compare to ftrace_stub) and ftrace_graph_entry (compare to
|
||||
ftrace_graph_entry_stub). If either of those are not set to the relevant stub
|
||||
ftrace_graph_entry_stub). If either of those is not set to the relevant stub
|
||||
function, call the arch-specific function ftrace_graph_caller which in turn
|
||||
calls the arch-specific function prepare_ftrace_return. Neither of these
|
||||
function names are strictly required, but you should use them anyways to stay
|
||||
function names is strictly required, but you should use them anyway to stay
|
||||
consistent across the architecture ports -- easier to compare & contrast
|
||||
things.
|
||||
|
||||
@ -144,7 +144,7 @@ but the first argument should be a pointer to the "frompc". Typically this is
|
||||
located on the stack. This allows the function to hijack the return address
|
||||
temporarily to have it point to the arch-specific function return_to_handler.
|
||||
That function will simply call the common ftrace_return_to_handler function and
|
||||
that will return the original return address with which, you can return to the
|
||||
that will return the original return address with which you can return to the
|
||||
original call site.
|
||||
|
||||
Here is the updated mcount pseudo code:
|
||||
|
||||
@ -44,7 +44,8 @@ Check for lost events.
|
||||
Usage
|
||||
-----
|
||||
|
||||
Make sure debugfs is mounted to /sys/kernel/debug. If not, (requires root privileges)
|
||||
Make sure debugfs is mounted to /sys/kernel/debug.
|
||||
If not (requires root privileges):
|
||||
$ mount -t debugfs debugfs /sys/kernel/debug
|
||||
|
||||
Check that the driver you are about to trace is not loaded.
|
||||
@ -91,7 +92,7 @@ $ dmesg > dmesg.txt
|
||||
$ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt
|
||||
and then send the .tar.gz file. The trace compresses considerably. Replace
|
||||
"pciid" and "nick" with the PCI ID or model name of your piece of hardware
|
||||
under investigation and your nick name.
|
||||
under investigation and your nickname.
|
||||
|
||||
|
||||
How Mmiotrace Works
|
||||
@ -100,7 +101,7 @@ How Mmiotrace Works
|
||||
Access to hardware IO-memory is gained by mapping addresses from PCI bus by
|
||||
calling one of the ioremap_*() functions. Mmiotrace is hooked into the
|
||||
__ioremap() function and gets called whenever a mapping is created. Mapping is
|
||||
an event that is recorded into the trace log. Note, that ISA range mappings
|
||||
an event that is recorded into the trace log. Note that ISA range mappings
|
||||
are not caught, since the mapping always exists and is returned directly.
|
||||
|
||||
MMIO accesses are recorded via page faults. Just before __ioremap() returns,
|
||||
@ -122,11 +123,11 @@ Trace Log Format
|
||||
----------------
|
||||
|
||||
The raw log is text and easily filtered with e.g. grep and awk. One record is
|
||||
one line in the log. A record starts with a keyword, followed by keyword
|
||||
dependant arguments. Arguments are separated by a space, or continue until the
|
||||
one line in the log. A record starts with a keyword, followed by keyword-
|
||||
dependent arguments. Arguments are separated by a space, or continue until the
|
||||
end of line. The format for version 20070824 is as follows:
|
||||
|
||||
Explanation Keyword Space separated arguments
|
||||
Explanation Keyword Space-separated arguments
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
read event R width, timestamp, map id, physical, value, PC, PID
|
||||
@ -136,7 +137,7 @@ iounmap event UNMAP timestamp, map id, PC, PID
|
||||
marker MARK timestamp, text
|
||||
version VERSION the string "20070824"
|
||||
info for reader LSPCI one line from lspci -v
|
||||
PCI address map PCIDEV space separated /proc/bus/pci/devices data
|
||||
PCI address map PCIDEV space-separated /proc/bus/pci/devices data
|
||||
unk. opcode UNKNOWN timestamp, map id, physical, data, PC, PID
|
||||
|
||||
Timestamp is in seconds with decimals. Physical is a PCI bus address, virtual
|
||||
|
||||
@ -33,9 +33,9 @@ head_page - a pointer to the page that the reader will use next
|
||||
|
||||
tail_page - a pointer to the page that will be written to next
|
||||
|
||||
commit_page - a pointer to the page with the last finished non nested write.
|
||||
commit_page - a pointer to the page with the last finished non-nested write.
|
||||
|
||||
cmpxchg - hardware assisted atomic transaction that performs the following:
|
||||
cmpxchg - hardware-assisted atomic transaction that performs the following:
|
||||
|
||||
A = B iff previous A == C
|
||||
|
||||
@ -52,15 +52,15 @@ The Generic Ring Buffer
|
||||
The ring buffer can be used in either an overwrite mode or in
|
||||
producer/consumer mode.
|
||||
|
||||
Producer/consumer mode is where the producer were to fill up the
|
||||
Producer/consumer mode is where if the producer were to fill up the
|
||||
buffer before the consumer could free up anything, the producer
|
||||
will stop writing to the buffer. This will lose most recent events.
|
||||
|
||||
Overwrite mode is where the produce were to fill up the buffer
|
||||
Overwrite mode is where if the producer were to fill up the buffer
|
||||
before the consumer could free up anything, the producer will
|
||||
overwrite the older data. This will lose the oldest events.
|
||||
|
||||
No two writers can write at the same time (on the same per cpu buffer),
|
||||
No two writers can write at the same time (on the same per-cpu buffer),
|
||||
but a writer may interrupt another writer, but it must finish writing
|
||||
before the previous writer may continue. This is very important to the
|
||||
algorithm. The writers act like a "stack". The way interrupts works
|
||||
@ -79,16 +79,16 @@ the interrupt doing a write as well.
|
||||
|
||||
Readers can happen at any time. But no two readers may run at the
|
||||
same time, nor can a reader preempt/interrupt another reader. A reader
|
||||
can not preempt/interrupt a writer, but it may read/consume from the
|
||||
cannot preempt/interrupt a writer, but it may read/consume from the
|
||||
buffer at the same time as a writer is writing, but the reader must be
|
||||
on another processor to do so. A reader may read on its own processor
|
||||
and can be preempted by a writer.
|
||||
|
||||
A writer can preempt a reader, but a reader can not preempt a writer.
|
||||
A writer can preempt a reader, but a reader cannot preempt a writer.
|
||||
But a reader can read the buffer at the same time (on another processor)
|
||||
as a writer.
|
||||
|
||||
The ring buffer is made up of a list of pages held together by a link list.
|
||||
The ring buffer is made up of a list of pages held together by a linked list.
|
||||
|
||||
At initialization a reader page is allocated for the reader that is not
|
||||
part of the ring buffer.
|
||||
@ -102,7 +102,7 @@ the head page.
|
||||
|
||||
The reader has its own page to use. At start up time, this page is
|
||||
allocated but is not attached to the list. When the reader wants
|
||||
to read from the buffer, if its page is empty (like it is on start up)
|
||||
to read from the buffer, if its page is empty (like it is on start-up),
|
||||
it will swap its page with the head_page. The old reader page will
|
||||
become part of the ring buffer and the head_page will be removed.
|
||||
The page after the inserted page (old reader_page) will become the
|
||||
@ -206,7 +206,7 @@ The main pointers:
|
||||
|
||||
commit page - the page that last finished a write.
|
||||
|
||||
The commit page only is updated by the outer most writer in the
|
||||
The commit page only is updated by the outermost writer in the
|
||||
writer stack. A writer that preempts another writer will not move the
|
||||
commit page.
|
||||
|
||||
@ -281,7 +281,7 @@ with the previous write.
|
||||
The commit pointer points to the last write location that was
|
||||
committed without preempting another write. When a write that
|
||||
preempted another write is committed, it only becomes a pending commit
|
||||
and will not be a full commit till all writes have been committed.
|
||||
and will not be a full commit until all writes have been committed.
|
||||
|
||||
The commit page points to the page that has the last full commit.
|
||||
The tail page points to the page with the last write (before
|
||||
@ -292,7 +292,7 @@ be several pages ahead. If the tail page catches up to the commit
|
||||
page then no more writes may take place (regardless of the mode
|
||||
of the ring buffer: overwrite and produce/consumer).
|
||||
|
||||
The order of pages are:
|
||||
The order of pages is:
|
||||
|
||||
head page
|
||||
commit page
|
||||
@ -311,7 +311,7 @@ Possible scenario:
|
||||
There is a special case that the head page is after either the commit page
|
||||
and possibly the tail page. That is when the commit (and tail) page has been
|
||||
swapped with the reader page. This is because the head page is always
|
||||
part of the ring buffer, but the reader page is not. When ever there
|
||||
part of the ring buffer, but the reader page is not. Whenever there
|
||||
has been less than a full page that has been committed inside the ring buffer,
|
||||
and a reader swaps out a page, it will be swapping out the commit page.
|
||||
|
||||
@ -338,7 +338,7 @@ and a reader swaps out a page, it will be swapping out the commit page.
|
||||
In this case, the head page will not move when the tail and commit
|
||||
move back into the ring buffer.
|
||||
|
||||
The reader can not swap a page into the ring buffer if the commit page
|
||||
The reader cannot swap a page into the ring buffer if the commit page
|
||||
is still on that page. If the read meets the last commit (real commit
|
||||
not pending or reserved), then there is nothing more to read.
|
||||
The buffer is considered empty until another full commit finishes.
|
||||
@ -395,7 +395,7 @@ The main idea behind the lockless algorithm is to combine the moving
|
||||
of the head_page pointer with the swapping of pages with the reader.
|
||||
State flags are placed inside the pointer to the page. To do this,
|
||||
each page must be aligned in memory by 4 bytes. This will allow the 2
|
||||
least significant bits of the address to be used as flags. Since
|
||||
least significant bits of the address to be used as flags, since
|
||||
they will always be zero for the address. To get the address,
|
||||
simply mask out the flags.
|
||||
|
||||
@ -460,7 +460,7 @@ When the reader tries to swap the page with the ring buffer, it
|
||||
will also use cmpxchg. If the flag bit in the pointer to the
|
||||
head page does not have the HEADER flag set, the compare will fail
|
||||
and the reader will need to look for the new head page and try again.
|
||||
Note, the flag UPDATE and HEADER are never set at the same time.
|
||||
Note, the flags UPDATE and HEADER are never set at the same time.
|
||||
|
||||
The reader swaps the reader page as follows:
|
||||
|
||||
@ -539,7 +539,7 @@ updated to the reader page.
|
||||
| +-----------------------------+ |
|
||||
+------------------------------------+
|
||||
|
||||
Another important point. The page that the reader page points back to
|
||||
Another important point: The page that the reader page points back to
|
||||
by its previous pointer (the one that now points to the new head page)
|
||||
never points back to the reader page. That is because the reader page is
|
||||
not part of the ring buffer. Traversing the ring buffer via the next pointers
|
||||
@ -572,7 +572,7 @@ not be able to swap the head page from the buffer, nor will it be able to
|
||||
move the head page, until the writer is finished with the move.
|
||||
|
||||
This eliminates any races that the reader can have on the writer. The reader
|
||||
must spin, and this is why the reader can not preempt the writer.
|
||||
must spin, and this is why the reader cannot preempt the writer.
|
||||
|
||||
tail page
|
||||
|
|
||||
@ -659,9 +659,9 @@ before pushing the head page. If it is, then it can be assumed that the
|
||||
tail page wrapped the buffer, and we must drop new writes.
|
||||
|
||||
This is not a race condition, because the commit page can only be moved
|
||||
by the outter most writer (the writer that was preempted).
|
||||
by the outermost writer (the writer that was preempted).
|
||||
This means that the commit will not move while a writer is moving the
|
||||
tail page. The reader can not swap the reader page if it is also being
|
||||
tail page. The reader cannot swap the reader page if it is also being
|
||||
used as the commit page. The reader can simply check that the commit
|
||||
is off the reader page. Once the commit page leaves the reader page
|
||||
it will never go back on it unless a reader does another swap with the
|
||||
@ -733,7 +733,7 @@ The write converts the head page pointer to UPDATE.
|
||||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
But if a nested writer preempts here. It will see that the next
|
||||
But if a nested writer preempts here, it will see that the next
|
||||
page is a head page, but it is also nested. It will detect that
|
||||
it is nested and will save that information. The detection is the
|
||||
fact that it sees the UPDATE flag instead of a HEADER or NORMAL
|
||||
@ -761,7 +761,7 @@ to NORMAL.
|
||||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
After the nested writer finishes, the outer most writer will convert
|
||||
After the nested writer finishes, the outermost writer will convert
|
||||
the UPDATE pointer to NORMAL.
|
||||
|
||||
|
||||
@ -812,7 +812,7 @@ head page.
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
The nested writer moves the tail page forward. But does not set the old
|
||||
update page to NORMAL because it is not the outer most writer.
|
||||
update page to NORMAL because it is not the outermost writer.
|
||||
|
||||
tail page
|
||||
|
|
||||
@ -892,7 +892,7 @@ It will return to the first writer.
|
||||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
The first writer can not know atomically test if the tail page moved
|
||||
The first writer cannot know atomically if the tail page moved
|
||||
while it updates the HEAD page. It will then update the head page to
|
||||
what it thinks is the new head page.
|
||||
|
||||
@ -923,9 +923,9 @@ if the tail page is either where it use to be or on the next page:
|
||||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
If tail page != A and tail page does not equal B, then it must reset the
|
||||
pointer back to NORMAL. The fact that it only needs to worry about
|
||||
nested writers, it only needs to check this after setting the HEAD page.
|
||||
If tail page != A and tail page != B, then it must reset the pointer
|
||||
back to NORMAL. The fact that it only needs to worry about nested
|
||||
writers means that it only needs to check this after setting the HEAD page.
|
||||
|
||||
|
||||
(first writer)
|
||||
@ -939,7 +939,7 @@ nested writers, it only needs to check this after setting the HEAD page.
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
Now the writer can update the head page. This is also why the head page must
|
||||
remain in UPDATE and only reset by the outer most writer. This prevents
|
||||
remain in UPDATE and only reset by the outermost writer. This prevents
|
||||
the reader from seeing the incorrect head page.
|
||||
|
||||
|
||||
|
||||
@ -10,8 +10,8 @@ Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
|
||||
creating custom kernel modules to register probe functions using the event
|
||||
tracing infrastructure.
|
||||
|
||||
Simplistically, tracepoints will represent an important event that when can
|
||||
be taken in conjunction with other tracepoints to build a "Big Picture" of
|
||||
Simplistically, tracepoints represent important events that can be
|
||||
taken in conjunction with other tracepoints to build a "Big Picture" of
|
||||
what is going on within the system. There are a large number of methods for
|
||||
gathering and interpreting these events. Lacking any current Best Practises,
|
||||
this document describes some of the methods that can be used.
|
||||
@ -33,12 +33,12 @@ calling
|
||||
|
||||
will give a fair indication of the number of events available.
|
||||
|
||||
2.2 PCL
|
||||
2.2 PCL (Performance Counters for Linux)
|
||||
-------
|
||||
|
||||
Discovery and enumeration of all counters and events, including tracepoints
|
||||
Discovery and enumeration of all counters and events, including tracepoints,
|
||||
are available with the perf tool. Getting a list of available events is a
|
||||
simple case of
|
||||
simple case of:
|
||||
|
||||
$ perf list 2>&1 | grep Tracepoint
|
||||
ext4:ext4_free_inode [Tracepoint event]
|
||||
@ -49,19 +49,19 @@ simple case of
|
||||
[ .... remaining output snipped .... ]
|
||||
|
||||
|
||||
2. Enabling Events
|
||||
3. Enabling Events
|
||||
==================
|
||||
|
||||
2.1 System-Wide Event Enabling
|
||||
3.1 System-Wide Event Enabling
|
||||
------------------------------
|
||||
|
||||
See Documentation/trace/events.txt for a proper description on how events
|
||||
can be enabled system-wide. A short example of enabling all events related
|
||||
to page allocation would look something like
|
||||
to page allocation would look something like:
|
||||
|
||||
$ for i in `find /sys/kernel/debug/tracing/events -name "enable" | grep mm_`; do echo 1 > $i; done
|
||||
|
||||
2.2 System-Wide Event Enabling with SystemTap
|
||||
3.2 System-Wide Event Enabling with SystemTap
|
||||
---------------------------------------------
|
||||
|
||||
In SystemTap, tracepoints are accessible using the kernel.trace() function
|
||||
@ -86,7 +86,7 @@ were allocating the pages.
|
||||
print_count()
|
||||
}
|
||||
|
||||
2.3 System-Wide Event Enabling with PCL
|
||||
3.3 System-Wide Event Enabling with PCL
|
||||
---------------------------------------
|
||||
|
||||
By specifying the -a switch and analysing sleep, the system-wide events
|
||||
@ -107,16 +107,16 @@ for a duration of time can be examined.
|
||||
Similarly, one could execute a shell and exit it as desired to get a report
|
||||
at that point.
|
||||
|
||||
2.4 Local Event Enabling
|
||||
3.4 Local Event Enabling
|
||||
------------------------
|
||||
|
||||
Documentation/trace/ftrace.txt describes how to enable events on a per-thread
|
||||
basis using set_ftrace_pid.
|
||||
|
||||
2.5 Local Event Enablement with PCL
|
||||
3.5 Local Event Enablement with PCL
|
||||
-----------------------------------
|
||||
|
||||
Events can be activate and tracked for the duration of a process on a local
|
||||
Events can be activated and tracked for the duration of a process on a local
|
||||
basis using PCL such as follows.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
@ -131,18 +131,18 @@ basis using PCL such as follows.
|
||||
|
||||
0.973913387 seconds time elapsed
|
||||
|
||||
3. Event Filtering
|
||||
4. Event Filtering
|
||||
==================
|
||||
|
||||
Documentation/trace/ftrace.txt covers in-depth how to filter events in
|
||||
ftrace. Obviously using grep and awk of trace_pipe is an option as well
|
||||
as any script reading trace_pipe.
|
||||
|
||||
4. Analysing Event Variances with PCL
|
||||
5. Analysing Event Variances with PCL
|
||||
=====================================
|
||||
|
||||
Any workload can exhibit variances between runs and it can be important
|
||||
to know what the standard deviation in. By and large, this is left to the
|
||||
to know what the standard deviation is. By and large, this is left to the
|
||||
performance analyst to do it by hand. In the event that the discrete event
|
||||
occurrences are useful to the performance analyst, then perf can be used.
|
||||
|
||||
@ -166,7 +166,7 @@ In the event that some higher-level event is required that depends on some
|
||||
aggregation of discrete events, then a script would need to be developed.
|
||||
|
||||
Using --repeat, it is also possible to view how events are fluctuating over
|
||||
time on a system wide basis using -a and sleep.
|
||||
time on a system-wide basis using -a and sleep.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
@ -180,7 +180,7 @@ time on a system wide basis using -a and sleep.
|
||||
|
||||
1.002251757 seconds time elapsed ( +- 0.005% )
|
||||
|
||||
5. Higher-Level Analysis with Helper Scripts
|
||||
6. Higher-Level Analysis with Helper Scripts
|
||||
============================================
|
||||
|
||||
When events are enabled the events that are triggering can be read from
|
||||
@ -190,11 +190,11 @@ be gathered on-line as appropriate. Examples of post-processing might include
|
||||
|
||||
o Reading information from /proc for the PID that triggered the event
|
||||
o Deriving a higher-level event from a series of lower-level events.
|
||||
o Calculate latencies between two events
|
||||
o Calculating latencies between two events
|
||||
|
||||
Documentation/trace/postprocess/trace-pagealloc-postprocess.pl is an example
|
||||
script that can read trace_pipe from STDIN or a copy of a trace. When used
|
||||
on-line, it can be interrupted once to generate a report without existing
|
||||
on-line, it can be interrupted once to generate a report without exiting
|
||||
and twice to exit.
|
||||
|
||||
Simplistically, the script just reads STDIN and counts up events but it
|
||||
@ -212,12 +212,12 @@ also can do more such as
|
||||
processes, the parent process responsible for creating all the helpers
|
||||
can be identified
|
||||
|
||||
6. Lower-Level Analysis with PCL
|
||||
7. Lower-Level Analysis with PCL
|
||||
================================
|
||||
|
||||
There may also be a requirement to identify what functions with a program
|
||||
There may also be a requirement to identify what functions within a program
|
||||
were generating events within the kernel. To begin this sort of analysis, the
|
||||
data must be recorded. At the time of writing, this required root
|
||||
data must be recorded. At the time of writing, this required root:
|
||||
|
||||
$ perf record -c 1 \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
@ -253,11 +253,11 @@ perf report.
|
||||
# (For more details, try: perf report --sort comm,dso,symbol)
|
||||
#
|
||||
|
||||
According to this, the vast majority of events occured triggered on events
|
||||
within the VDSO. With simple binaries, this will often be the case so lets
|
||||
According to this, the vast majority of events triggered on events
|
||||
within the VDSO. With simple binaries, this will often be the case so let's
|
||||
take a slightly different example. In the course of writing this, it was
|
||||
noticed that X was generating an insane amount of page allocations so lets look
|
||||
at it
|
||||
noticed that X was generating an insane amount of page allocations so let's look
|
||||
at it:
|
||||
|
||||
$ perf record -c 1 -f \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
@ -280,8 +280,8 @@ This was interrupted after a few seconds and
|
||||
# (For more details, try: perf report --sort comm,dso,symbol)
|
||||
#
|
||||
|
||||
So, almost half of the events are occuring in a library. To get an idea which
|
||||
symbol.
|
||||
So, almost half of the events are occurring in a library. To get an idea which
|
||||
symbol:
|
||||
|
||||
$ perf report --sort comm,dso,symbol
|
||||
# Samples: 27666
|
||||
@ -297,7 +297,7 @@ symbol.
|
||||
0.01% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 [.] get_fast_path
|
||||
0.00% Xorg [kernel] [k] ftrace_trace_userstack
|
||||
|
||||
To see where within the function pixmanFillsse2 things are going wrong
|
||||
To see where within the function pixmanFillsse2 things are going wrong:
|
||||
|
||||
$ perf annotate pixmanFillsse2
|
||||
[ ... ]
|
||||
|
||||
@ -103,7 +103,7 @@ I.2 libpciaccess
|
||||
----------------
|
||||
|
||||
To use the vga arbiter char device it was implemented an API inside the
|
||||
libpciaccess library. One fieldd was added to struct pci_device (each device
|
||||
libpciaccess library. One field was added to struct pci_device (each device
|
||||
on the system):
|
||||
|
||||
/* the type of resource decoded by the device */
|
||||
|
||||
80
MAINTAINERS
80
MAINTAINERS
@ -410,9 +410,8 @@ F: drivers/i2c/busses/i2c-ali1563.c
|
||||
|
||||
ALPHA PORT
|
||||
M: Richard Henderson <rth@twiddle.net>
|
||||
S: Odd Fixes for 2.4; Maintained for 2.6.
|
||||
M: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
|
||||
S: Maintained for 2.4; PCI support for 2.6.
|
||||
M: Matt Turner <mattst88@gmail.com>
|
||||
L: linux-alpha@vger.kernel.org
|
||||
F: arch/alpha/
|
||||
|
||||
@ -988,7 +987,6 @@ F: drivers/platform/x86/asus-laptop.c
|
||||
|
||||
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Maciej Sosnowski <maciej.sosnowski@intel.com>
|
||||
W: http://sourceforge.net/projects/xscaleiop
|
||||
S: Supported
|
||||
F: Documentation/crypto/async-tx-api.txt
|
||||
@ -1472,6 +1470,12 @@ L: linux-scsi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/scsi/fnic/
|
||||
|
||||
CMPC ACPI DRIVER
|
||||
M: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
|
||||
M: Daniel Oliveira Nascimento <don@syst.com.br>
|
||||
S: Supported
|
||||
F: drivers/platform/x86/classmate-laptop.c
|
||||
|
||||
CODA FILE SYSTEM
|
||||
M: Jan Harkes <jaharkes@cs.cmu.edu>
|
||||
M: coda@cs.cmu.edu
|
||||
@ -1632,9 +1636,8 @@ S: Maintained
|
||||
F: sound/pci/cs5535audio/
|
||||
|
||||
CX18 VIDEO4LINUX DRIVER
|
||||
M: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
M: Andy Walls <awalls@radix.net>
|
||||
L: ivtv-devel@ivtvdriver.org
|
||||
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://linuxtv.org
|
||||
@ -1819,7 +1822,6 @@ S: Supported
|
||||
F: fs/dlm/
|
||||
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
M: Maciej Sosnowski <maciej.sosnowski@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Supported
|
||||
F: drivers/dma/
|
||||
@ -2163,10 +2165,9 @@ F: drivers/hwmon/f75375s.c
|
||||
F: include/linux/f75375s.h
|
||||
|
||||
FIREWIRE SUBSYSTEM
|
||||
M: Kristian Hoegsberg <krh@redhat.com>
|
||||
M: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
L: linux1394-devel@lists.sourceforge.net
|
||||
W: http://www.linux1394.org/
|
||||
W: http://ieee1394.wiki.kernel.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
|
||||
S: Maintained
|
||||
F: drivers/firewire/
|
||||
@ -2699,22 +2700,14 @@ S: Supported
|
||||
F: drivers/idle/i7300_idle.c
|
||||
|
||||
IEEE 1394 SUBSYSTEM
|
||||
M: Ben Collins <ben.collins@ubuntu.com>
|
||||
M: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
L: linux1394-devel@lists.sourceforge.net
|
||||
W: http://www.linux1394.org/
|
||||
W: http://ieee1394.wiki.kernel.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
|
||||
S: Maintained
|
||||
S: Obsolete
|
||||
F: Documentation/debugging-via-ohci1394.txt
|
||||
F: drivers/ieee1394/
|
||||
|
||||
IEEE 1394 RAW I/O DRIVER
|
||||
M: Dan Dennedy <dan@dennedy.org>
|
||||
M: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
L: linux1394-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/ieee1394/raw1394*
|
||||
|
||||
IEEE 802.15.4 SUBSYSTEM
|
||||
M: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
M: Sergey Lapin <slapin@ossfans.org>
|
||||
@ -2791,7 +2784,7 @@ F: arch/x86/kernel/microcode_core.c
|
||||
F: arch/x86/kernel/microcode_intel.c
|
||||
|
||||
INTEL I/OAT DMA DRIVER
|
||||
M: Maciej Sosnowski <maciej.sosnowski@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Supported
|
||||
F: drivers/dma/ioat*
|
||||
|
||||
@ -2829,10 +2822,11 @@ L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/ixp2000/
|
||||
|
||||
INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/ixgb/ixgbe)
|
||||
INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/igbvf/ixgb/ixgbe)
|
||||
M: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
||||
M: Jesse Brandeburg <jesse.brandeburg@intel.com>
|
||||
M: Bruce Allan <bruce.w.allan@intel.com>
|
||||
M: Alex Duyck <alexander.h.duyck@intel.com>
|
||||
M: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
|
||||
M: John Ronciak <john.ronciak@intel.com>
|
||||
L: e1000-devel@lists.sourceforge.net
|
||||
@ -2842,6 +2836,7 @@ F: drivers/net/e100.c
|
||||
F: drivers/net/e1000/
|
||||
F: drivers/net/e1000e/
|
||||
F: drivers/net/igb/
|
||||
F: drivers/net/igbvf/
|
||||
F: drivers/net/ixgb/
|
||||
F: drivers/net/ixgbe/
|
||||
|
||||
@ -3015,8 +3010,8 @@ S: Maintained
|
||||
F: drivers/isdn/hardware/eicon/
|
||||
|
||||
IVTV VIDEO4LINUX DRIVER
|
||||
M: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
L: ivtv-devel@ivtvdriver.org
|
||||
M: Andy Walls <awalls@radix.net>
|
||||
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.ivtvdriver.org
|
||||
@ -3646,6 +3641,11 @@ W: http://0pointer.de/lennart/tchibo.html
|
||||
S: Maintained
|
||||
F: drivers/platform/x86/msi-laptop.c
|
||||
|
||||
MSI WMI SUPPORT
|
||||
M: Anisse Astier <anisse@astier.eu>
|
||||
S: Supported
|
||||
F: drivers/platform/x86/msi-wmi.c
|
||||
|
||||
MULTIFUNCTION DEVICES (MFD)
|
||||
M: Samuel Ortiz <sameo@linux.intel.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
|
||||
@ -3836,6 +3836,7 @@ NETWORKING DRIVERS
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.linuxfoundation.org/en/Net
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
|
||||
S: Odd Fixes
|
||||
F: drivers/net/
|
||||
F: include/linux/if_*
|
||||
@ -3871,7 +3872,7 @@ F: drivers/net/ni5010.*
|
||||
|
||||
NILFS2 FILESYSTEM
|
||||
M: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
|
||||
L: users@nilfs.org
|
||||
L: linux-nilfs@vger.kernel.org
|
||||
W: http://www.nilfs.org/en/
|
||||
S: Supported
|
||||
F: Documentation/filesystems/nilfs2.txt
|
||||
@ -3938,29 +3939,20 @@ S: Maintained
|
||||
F: sound/soc/omap/
|
||||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
M: Imre Deak <imre.deak@nokia.com>
|
||||
M: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/omap/
|
||||
|
||||
OMAP DISPLAY SUBSYSTEM SUPPORT (DSS2)
|
||||
OMAP DISPLAY SUBSYSTEM and FRAMEBUFFER SUPPORT (DSS2)
|
||||
M: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
L: linux-fbdev@vger.kernel.org (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/omap2/dss/
|
||||
F: drivers/video/omap2/vrfb.c
|
||||
F: drivers/video/omap2/vram.c
|
||||
F: drivers/video/omap2/
|
||||
F: Documentation/arm/OMAP/DSS
|
||||
|
||||
OMAP FRAMEBUFFER SUPPORT (FOR DSS2)
|
||||
M: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
L: linux-fbdev@vger.kernel.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/video/omap2/omapfb/
|
||||
|
||||
OMAP MMC SUPPORT
|
||||
M: Jarkko Lavinen <jarkko.lavinen@nokia.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
@ -4452,6 +4444,13 @@ S: Supported
|
||||
F: Documentation/networking/LICENSE.qla3xxx
|
||||
F: drivers/net/qla3xxx.*
|
||||
|
||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||
M: Amit Kumar Salecha <amit.salecha@qlogic.com>
|
||||
M: linux-driver@qlogic.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/qlcnic/
|
||||
|
||||
QLOGIC QLGE 10Gb ETHERNET DRIVER
|
||||
M: Ron Mercer <ron.mercer@qlogic.com>
|
||||
M: linux-driver@qlogic.com
|
||||
@ -5803,6 +5802,15 @@ S: Maintained
|
||||
F: Documentation/filesystems/vfat.txt
|
||||
F: fs/fat/
|
||||
|
||||
VIRTIO HOST (VHOST)
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
L: virtualization@lists.osdl.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/vhost/
|
||||
F: include/linux/vhost.h
|
||||
|
||||
VIA RHINE NETWORK DRIVER
|
||||
M: Roger Luethi <rl@hellgate.ch>
|
||||
S: Maintained
|
||||
|
||||
5
Makefile
5
Makefile
@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 33
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc5
|
||||
NAME = Man-Eating Seals of Antiquity
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -18,10 +18,9 @@ MAKEFLAGS += -rR --no-print-directory
|
||||
|
||||
# Avoid funny character set dependencies
|
||||
unexport LC_ALL
|
||||
LC_CTYPE=C
|
||||
LC_COLLATE=C
|
||||
LC_NUMERIC=C
|
||||
export LC_CTYPE LC_COLLATE LC_NUMERIC
|
||||
export LC_COLLATE LC_NUMERIC
|
||||
|
||||
# We are using a recursive build, so we need to do a little thinking
|
||||
# to get the ordering right.
|
||||
|
||||
@ -28,6 +28,9 @@ static const struct cpumask *cpumask_of_node(int node)
|
||||
{
|
||||
int cpu;
|
||||
|
||||
if (node == -1)
|
||||
return cpu_all_mask;
|
||||
|
||||
cpumask_clear(&node_to_cpumask_map[node]);
|
||||
|
||||
for_each_online_cpu(cpu) {
|
||||
|
||||
@ -18,6 +18,8 @@ config ARM
|
||||
select HAVE_KRETPROBES if (HAVE_KPROBES)
|
||||
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
|
||||
select HAVE_GENERIC_DMA_COHERENT
|
||||
select HAVE_KERNEL_GZIP
|
||||
select HAVE_KERNEL_LZO
|
||||
help
|
||||
The ARM series is a line of low-power-consumption RISC chip designs
|
||||
licensed by ARM Ltd and targeted at embedded applications and
|
||||
@ -688,6 +690,7 @@ config ARCH_DAVINCI
|
||||
select HAVE_IDE
|
||||
select COMMON_CLKDEV
|
||||
select GENERIC_ALLOCATOR
|
||||
select ARCH_HAS_HOLES_MEMORYMODEL
|
||||
help
|
||||
Support for TI's DaVinci platform.
|
||||
|
||||
@ -726,14 +729,26 @@ config ARCH_U8500
|
||||
|
||||
endchoice
|
||||
|
||||
source "arch/arm/mach-aaec2000/Kconfig"
|
||||
|
||||
source "arch/arm/mach-at91/Kconfig"
|
||||
|
||||
source "arch/arm/mach-bcmring/Kconfig"
|
||||
|
||||
source "arch/arm/mach-clps711x/Kconfig"
|
||||
|
||||
source "arch/arm/mach-davinci/Kconfig"
|
||||
|
||||
source "arch/arm/mach-dove/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ep93xx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-footbridge/Kconfig"
|
||||
|
||||
source "arch/arm/mach-gemini/Kconfig"
|
||||
|
||||
source "arch/arm/mach-h720x/Kconfig"
|
||||
|
||||
source "arch/arm/mach-integrator/Kconfig"
|
||||
|
||||
source "arch/arm/mach-iop32x/Kconfig"
|
||||
@ -748,16 +763,26 @@ source "arch/arm/mach-ixp2000/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ixp23xx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-kirkwood/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ks8695/Kconfig"
|
||||
|
||||
source "arch/arm/mach-lh7a40x/Kconfig"
|
||||
|
||||
source "arch/arm/mach-loki/Kconfig"
|
||||
|
||||
source "arch/arm/mach-msm/Kconfig"
|
||||
|
||||
source "arch/arm/mach-mv78xx0/Kconfig"
|
||||
|
||||
source "arch/arm/mach-pxa/Kconfig"
|
||||
source "arch/arm/plat-pxa/Kconfig"
|
||||
source "arch/arm/plat-mxc/Kconfig"
|
||||
|
||||
source "arch/arm/mach-mmp/Kconfig"
|
||||
source "arch/arm/mach-netx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-sa1100/Kconfig"
|
||||
source "arch/arm/mach-nomadik/Kconfig"
|
||||
source "arch/arm/plat-nomadik/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ns9xxx/Kconfig"
|
||||
|
||||
source "arch/arm/plat-omap/Kconfig"
|
||||
|
||||
@ -767,9 +792,14 @@ source "arch/arm/mach-omap2/Kconfig"
|
||||
|
||||
source "arch/arm/mach-orion5x/Kconfig"
|
||||
|
||||
source "arch/arm/mach-kirkwood/Kconfig"
|
||||
source "arch/arm/mach-pxa/Kconfig"
|
||||
source "arch/arm/plat-pxa/Kconfig"
|
||||
|
||||
source "arch/arm/mach-dove/Kconfig"
|
||||
source "arch/arm/mach-mmp/Kconfig"
|
||||
|
||||
source "arch/arm/mach-realview/Kconfig"
|
||||
|
||||
source "arch/arm/mach-sa1100/Kconfig"
|
||||
|
||||
source "arch/arm/plat-samsung/Kconfig"
|
||||
source "arch/arm/plat-s3c24xx/Kconfig"
|
||||
@ -797,41 +827,14 @@ if ARCH_S5PC1XX
|
||||
source "arch/arm/mach-s5pc100/Kconfig"
|
||||
endif
|
||||
|
||||
source "arch/arm/mach-lh7a40x/Kconfig"
|
||||
source "arch/arm/mach-u300/Kconfig"
|
||||
|
||||
source "arch/arm/mach-h720x/Kconfig"
|
||||
source "arch/arm/mach-ux500/Kconfig"
|
||||
|
||||
source "arch/arm/mach-versatile/Kconfig"
|
||||
|
||||
source "arch/arm/mach-aaec2000/Kconfig"
|
||||
|
||||
source "arch/arm/mach-realview/Kconfig"
|
||||
|
||||
source "arch/arm/mach-at91/Kconfig"
|
||||
|
||||
source "arch/arm/plat-mxc/Kconfig"
|
||||
|
||||
source "arch/arm/mach-nomadik/Kconfig"
|
||||
source "arch/arm/plat-nomadik/Kconfig"
|
||||
|
||||
source "arch/arm/mach-netx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ns9xxx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-davinci/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ks8695/Kconfig"
|
||||
|
||||
source "arch/arm/mach-msm/Kconfig"
|
||||
|
||||
source "arch/arm/mach-u300/Kconfig"
|
||||
|
||||
source "arch/arm/mach-w90x900/Kconfig"
|
||||
|
||||
source "arch/arm/mach-bcmring/Kconfig"
|
||||
|
||||
source "arch/arm/mach-ux500/Kconfig"
|
||||
|
||||
# Definitions to make life easier
|
||||
config ARCH_ACORN
|
||||
bool
|
||||
|
||||
@ -146,6 +146,7 @@ machine-$(CONFIG_ARCH_MX1) := mx1
|
||||
machine-$(CONFIG_ARCH_MX2) := mx2
|
||||
machine-$(CONFIG_ARCH_MX25) := mx25
|
||||
machine-$(CONFIG_ARCH_MX3) := mx3
|
||||
machine-$(CONFIG_ARCH_MXC91231) := mxc91231
|
||||
machine-$(CONFIG_ARCH_NETX) := netx
|
||||
machine-$(CONFIG_ARCH_NOMADIK) := nomadik
|
||||
machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx
|
||||
@ -171,12 +172,12 @@ machine-$(CONFIG_ARCH_U8500) := ux500
|
||||
machine-$(CONFIG_ARCH_VERSATILE) := versatile
|
||||
machine-$(CONFIG_ARCH_W90X900) := w90x900
|
||||
machine-$(CONFIG_FOOTBRIDGE) := footbridge
|
||||
machine-$(CONFIG_ARCH_MXC91231) := mxc91231
|
||||
|
||||
# Platform directory name. This list is sorted alphanumerically
|
||||
# by CONFIG_* macro name.
|
||||
plat-$(CONFIG_ARCH_MXC) := mxc
|
||||
plat-$(CONFIG_ARCH_OMAP) := omap
|
||||
plat-$(CONFIG_ARCH_STMP3XXX) := stmp3xxx
|
||||
plat-$(CONFIG_PLAT_IOP) := iop
|
||||
plat-$(CONFIG_PLAT_NOMADIK) := nomadik
|
||||
plat-$(CONFIG_PLAT_ORION) := orion
|
||||
@ -184,7 +185,6 @@ plat-$(CONFIG_PLAT_PXA) := pxa
|
||||
plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx s3c samsung
|
||||
plat-$(CONFIG_PLAT_S3C64XX) := s3c64xx s3c samsung
|
||||
plat-$(CONFIG_PLAT_S5PC1XX) := s5pc1xx s3c samsung
|
||||
plat-$(CONFIG_ARCH_STMP3XXX) := stmp3xxx
|
||||
|
||||
ifeq ($(CONFIG_ARCH_EBSA110),y)
|
||||
# This is what happens if you forget the IOCS16 line.
|
||||
|
||||
@ -63,8 +63,12 @@ endif
|
||||
|
||||
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/
|
||||
|
||||
targets := vmlinux vmlinux.lds piggy.gz piggy.o font.o font.c \
|
||||
head.o misc.o $(OBJS)
|
||||
suffix_$(CONFIG_KERNEL_GZIP) = gzip
|
||||
suffix_$(CONFIG_KERNEL_LZO) = lzo
|
||||
|
||||
targets := vmlinux vmlinux.lds \
|
||||
piggy.$(suffix_y) piggy.$(suffix_y).o \
|
||||
font.o font.c head.o misc.o $(OBJS)
|
||||
|
||||
ifeq ($(CONFIG_FUNCTION_TRACER),y)
|
||||
ORIG_CFLAGS := $(KBUILD_CFLAGS)
|
||||
@ -87,22 +91,34 @@ endif
|
||||
ifneq ($(PARAMS_PHYS),)
|
||||
LDFLAGS_vmlinux += --defsym params_phys=$(PARAMS_PHYS)
|
||||
endif
|
||||
LDFLAGS_vmlinux += -p --no-undefined -X \
|
||||
$(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name) -T
|
||||
# ?
|
||||
LDFLAGS_vmlinux += -p
|
||||
# Report unresolved symbol references
|
||||
LDFLAGS_vmlinux += --no-undefined
|
||||
# Delete all temporary local symbols
|
||||
LDFLAGS_vmlinux += -X
|
||||
# Next argument is a linker script
|
||||
LDFLAGS_vmlinux += -T
|
||||
|
||||
# For __aeabi_uidivmod
|
||||
lib1funcs = $(obj)/lib1funcs.o
|
||||
|
||||
$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE
|
||||
$(call cmd,shipped)
|
||||
|
||||
# Don't allow any static data in misc.o, which
|
||||
# would otherwise mess up our GOT table
|
||||
CFLAGS_misc.o := -Dstatic=
|
||||
|
||||
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
|
||||
$(addprefix $(obj)/, $(OBJS)) FORCE
|
||||
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
|
||||
$(addprefix $(obj)/, $(OBJS)) $(lib1funcs) FORCE
|
||||
$(call if_changed,ld)
|
||||
@:
|
||||
|
||||
$(obj)/piggy.gz: $(obj)/../Image FORCE
|
||||
$(call if_changed,gzip)
|
||||
$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
|
||||
$(call if_changed,$(suffix_y))
|
||||
|
||||
$(obj)/piggy.o: $(obj)/piggy.gz FORCE
|
||||
$(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) FORCE
|
||||
|
||||
CFLAGS_font.o := -Dstatic=
|
||||
|
||||
|
||||
@ -27,6 +27,14 @@
|
||||
.macro writeb, ch, rb
|
||||
mcr p14, 0, \ch, c0, c5, 0
|
||||
.endm
|
||||
#elif defined(CONFIG_CPU_V7)
|
||||
.macro loadsp, rb
|
||||
.endm
|
||||
.macro writeb, ch, rb
|
||||
wait: mrc p14, 0, pc, c0, c1, 0
|
||||
bcs wait
|
||||
mcr p14, 0, \ch, c0, c5, 0
|
||||
.endm
|
||||
#elif defined(CONFIG_CPU_XSCALE)
|
||||
.macro loadsp, rb
|
||||
.endm
|
||||
|
||||
@ -18,10 +18,15 @@
|
||||
|
||||
unsigned int __machine_arch_type;
|
||||
|
||||
#define _LINUX_STRING_H_
|
||||
|
||||
#include <linux/compiler.h> /* for inline */
|
||||
#include <linux/types.h> /* for size_t */
|
||||
#include <linux/stddef.h> /* for NULL */
|
||||
#include <asm/string.h>
|
||||
#include <linux/linkage.h>
|
||||
|
||||
#include <asm/unaligned.h>
|
||||
|
||||
#ifdef STANDALONE_DEBUG
|
||||
#define putstr printf
|
||||
@ -48,6 +53,18 @@ static void icedcc_putc(int ch)
|
||||
|
||||
asm("mcr p14, 0, %0, c0, c5, 0" : : "r" (ch));
|
||||
}
|
||||
|
||||
#elif defined(CONFIG_CPU_V7)
|
||||
|
||||
static void icedcc_putc(int ch)
|
||||
{
|
||||
asm(
|
||||
"wait: mrc p14, 0, pc, c0, c1, 0 \n\
|
||||
bcs wait \n\
|
||||
mcr p14, 0, %0, c0, c5, 0 "
|
||||
: : "r" (ch));
|
||||
}
|
||||
|
||||
#elif defined(CONFIG_CPU_XSCALE)
|
||||
|
||||
static void icedcc_putc(int ch)
|
||||
@ -83,7 +100,6 @@ static void icedcc_putc(int ch)
|
||||
#endif
|
||||
|
||||
#define putc(ch) icedcc_putc(ch)
|
||||
#define flush() do { } while (0)
|
||||
#endif
|
||||
|
||||
static void putstr(const char *ptr)
|
||||
@ -188,34 +204,8 @@ static inline __ptr_t memcpy(__ptr_t __dest, __const __ptr_t __src,
|
||||
/*
|
||||
* gzip delarations
|
||||
*/
|
||||
#define OF(args) args
|
||||
#define STATIC static
|
||||
|
||||
typedef unsigned char uch;
|
||||
typedef unsigned short ush;
|
||||
typedef unsigned long ulg;
|
||||
|
||||
#define WSIZE 0x8000 /* Window size must be at least 32k, */
|
||||
/* and a power of two */
|
||||
|
||||
static uch *inbuf; /* input buffer */
|
||||
static uch window[WSIZE]; /* Sliding window buffer */
|
||||
|
||||
static unsigned insize; /* valid bytes in inbuf */
|
||||
static unsigned inptr; /* index of next byte to be processed in inbuf */
|
||||
static unsigned outcnt; /* bytes in output buffer */
|
||||
|
||||
/* gzip flag byte */
|
||||
#define ASCII_FLAG 0x01 /* bit 0 set: file probably ascii text */
|
||||
#define CONTINUATION 0x02 /* bit 1 set: continuation of multi-part gzip file */
|
||||
#define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */
|
||||
#define ORIG_NAME 0x08 /* bit 3 set: original file name present */
|
||||
#define COMMENT 0x10 /* bit 4 set: file comment present */
|
||||
#define ENCRYPTED 0x20 /* bit 5 set: file is encrypted */
|
||||
#define RESERVED 0xC0 /* bit 6,7: reserved */
|
||||
|
||||
#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())
|
||||
|
||||
/* Diagnostic functions */
|
||||
#ifdef DEBUG
|
||||
# define Assert(cond,msg) {if(!(cond)) error(msg);}
|
||||
@ -233,24 +223,20 @@ static unsigned outcnt; /* bytes in output buffer */
|
||||
# define Tracecv(c,x)
|
||||
#endif
|
||||
|
||||
static int fill_inbuf(void);
|
||||
static void flush_window(void);
|
||||
static void error(char *m);
|
||||
|
||||
extern char input_data[];
|
||||
extern char input_data_end[];
|
||||
|
||||
static uch *output_data;
|
||||
static ulg output_ptr;
|
||||
static ulg bytes_out;
|
||||
static unsigned char *output_data;
|
||||
static unsigned long output_ptr;
|
||||
|
||||
static void error(char *m);
|
||||
|
||||
static void putstr(const char *);
|
||||
|
||||
extern int end;
|
||||
static ulg free_mem_ptr;
|
||||
static ulg free_mem_end_ptr;
|
||||
static unsigned long free_mem_ptr;
|
||||
static unsigned long free_mem_end_ptr;
|
||||
|
||||
#ifdef STANDALONE_DEBUG
|
||||
#define NO_INFLATE_MALLOC
|
||||
@ -258,46 +244,13 @@ static ulg free_mem_end_ptr;
|
||||
|
||||
#define ARCH_HAS_DECOMP_WDOG
|
||||
|
||||
#include "../../../../lib/inflate.c"
|
||||
#ifdef CONFIG_KERNEL_GZIP
|
||||
#include "../../../../lib/decompress_inflate.c"
|
||||
#endif
|
||||
|
||||
/* ===========================================================================
|
||||
* Fill the input buffer. This is called only when the buffer is empty
|
||||
* and at least one byte is really needed.
|
||||
*/
|
||||
int fill_inbuf(void)
|
||||
{
|
||||
if (insize != 0)
|
||||
error("ran out of input data");
|
||||
|
||||
inbuf = input_data;
|
||||
insize = &input_data_end[0] - &input_data[0];
|
||||
|
||||
inptr = 1;
|
||||
return inbuf[0];
|
||||
}
|
||||
|
||||
/* ===========================================================================
|
||||
* Write the output window window[0..outcnt-1] and update crc and bytes_out.
|
||||
* (Used for the decompressed data only.)
|
||||
*/
|
||||
void flush_window(void)
|
||||
{
|
||||
ulg c = crc;
|
||||
unsigned n;
|
||||
uch *in, *out, ch;
|
||||
|
||||
in = window;
|
||||
out = &output_data[output_ptr];
|
||||
for (n = 0; n < outcnt; n++) {
|
||||
ch = *out++ = *in++;
|
||||
c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
|
||||
}
|
||||
crc = c;
|
||||
bytes_out += (ulg)outcnt;
|
||||
output_ptr += (ulg)outcnt;
|
||||
outcnt = 0;
|
||||
putstr(".");
|
||||
}
|
||||
#ifdef CONFIG_KERNEL_LZO
|
||||
#include "../../../../lib/decompress_unlzo.c"
|
||||
#endif
|
||||
|
||||
#ifndef arch_error
|
||||
#define arch_error(x)
|
||||
@ -314,22 +267,33 @@ static void error(char *x)
|
||||
while(1); /* Halt */
|
||||
}
|
||||
|
||||
asmlinkage void __div0(void)
|
||||
{
|
||||
error("Attempting division by 0!");
|
||||
}
|
||||
|
||||
#ifndef STANDALONE_DEBUG
|
||||
|
||||
ulg
|
||||
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
|
||||
int arch_id)
|
||||
unsigned long
|
||||
decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
|
||||
unsigned long free_mem_ptr_end_p,
|
||||
int arch_id)
|
||||
{
|
||||
output_data = (uch *)output_start; /* Points to kernel start */
|
||||
unsigned char *tmp;
|
||||
|
||||
output_data = (unsigned char *)output_start;
|
||||
free_mem_ptr = free_mem_ptr_p;
|
||||
free_mem_end_ptr = free_mem_ptr_end_p;
|
||||
__machine_arch_type = arch_id;
|
||||
|
||||
arch_decomp_setup();
|
||||
|
||||
makecrc();
|
||||
tmp = (unsigned char *) (((unsigned long)input_data_end) - 4);
|
||||
output_ptr = get_unaligned_le32(tmp);
|
||||
|
||||
putstr("Uncompressing Linux...");
|
||||
gunzip();
|
||||
decompress(input_data, input_data_end - input_data,
|
||||
NULL, NULL, output_data, NULL, error);
|
||||
putstr(" done, booting the kernel.\n");
|
||||
return output_ptr;
|
||||
}
|
||||
@ -341,11 +305,10 @@ int main()
|
||||
{
|
||||
output_data = output_buffer;
|
||||
|
||||
makecrc();
|
||||
putstr("Uncompressing Linux...");
|
||||
gunzip();
|
||||
decompress(input_data, input_data_end - input_data,
|
||||
NULL, NULL, output_data, NULL, error);
|
||||
putstr("done.\n");
|
||||
return 0;
|
||||
}
|
||||
#endif
|
||||
|
||||
|
||||
6
arch/arm/boot/compressed/piggy.gzip.S
Normal file
6
arch/arm/boot/compressed/piggy.gzip.S
Normal file
@ -0,0 +1,6 @@
|
||||
.section .piggydata,#alloc
|
||||
.globl input_data
|
||||
input_data:
|
||||
.incbin "arch/arm/boot/compressed/piggy.gzip"
|
||||
.globl input_data_end
|
||||
input_data_end:
|
||||
@ -1,6 +1,6 @@
|
||||
.section .piggydata,#alloc
|
||||
.globl input_data
|
||||
input_data:
|
||||
.incbin "arch/arm/boot/compressed/piggy.gz"
|
||||
.incbin "arch/arm/boot/compressed/piggy.lzo"
|
||||
.globl input_data_end
|
||||
input_data_end:
|
||||
@ -312,7 +312,7 @@ static inline void unmap_single(struct device *dev, dma_addr_t dma_addr,
|
||||
* we need to ensure that the data will be coherent
|
||||
* with user mappings.
|
||||
*/
|
||||
__cpuc_flush_kernel_dcache_area(ptr, size);
|
||||
__cpuc_flush_dcache_area(ptr, size);
|
||||
}
|
||||
free_safe_buffer(dev->archdata.dmabounce, buf);
|
||||
}
|
||||
|
||||
@ -187,7 +187,6 @@ CONFIG_MACH_ACS5K=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM922T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -186,7 +186,6 @@ CONFIG_MACH_ACS5K=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM922T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -227,7 +227,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -189,7 +189,6 @@ CONFIG_PXA25x=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -233,7 +233,6 @@ CONFIG_MACH_OMAP3517EVM=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_32v6K=y
|
||||
CONFIG_CPU_V7=y
|
||||
CONFIG_CPU_32v7=y
|
||||
|
||||
@ -210,7 +210,6 @@ CONFIG_OMAP_ARM_150MHZ=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM925T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -101,7 +101,6 @@ CONFIG_SA1100_ASSABET=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -130,7 +130,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -129,7 +129,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -188,7 +188,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -187,7 +187,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -179,7 +179,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -132,7 +132,6 @@ CONFIG_MACH_ATEB9200=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -103,7 +103,6 @@ CONFIG_SA1100_BADGE4=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -181,7 +181,6 @@ CONFIG_BCM_ZRELADDR=0x8000
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_V6=y
|
||||
CONFIG_CPU_32v6K=y
|
||||
CONFIG_CPU_32v6=y
|
||||
|
||||
@ -196,7 +196,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -97,7 +97,6 @@ CONFIG_MACH_CARMEVA=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -105,7 +105,6 @@ CONFIG_SA1100_CERF_FLASH_16MB=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -236,7 +236,6 @@ CONFIG_MACH_CM_T35=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_32v6K=y
|
||||
CONFIG_CPU_V7=y
|
||||
CONFIG_CPU_32v7=y
|
||||
|
||||
@ -205,7 +205,6 @@ CONFIG_PXA_SSP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -247,7 +247,6 @@ CONFIG_PLAT_PXA=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSC3=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -204,7 +204,6 @@ CONFIG_PXA27x=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -212,7 +212,6 @@ CONFIG_PXA3xx=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSC3=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -125,7 +125,6 @@ CONFIG_SA1100_COLLIE=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -214,7 +214,6 @@ CONFIG_PXA_HAVE_BOARD_IRQS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -229,7 +229,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -219,7 +219,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -230,7 +230,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -193,7 +193,6 @@ CONFIG_AT91_TIMER_HZ=128
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -215,7 +215,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -225,7 +225,6 @@ CONFIG_DAVINCI_RESET_CLOCKS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -223,7 +223,6 @@ CONFIG_DAVINCI_RESET_CLOCKS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5TJ=y
|
||||
|
||||
@ -186,7 +186,6 @@ CONFIG_PLAT_ORION=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_V6=y
|
||||
CONFIG_CPU_32v6K=y
|
||||
CONFIG_CPU_32v6=y
|
||||
|
||||
@ -83,7 +83,6 @@ CONFIG_ARCH_EBSA110=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA110=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -186,7 +186,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -90,7 +90,6 @@ CONFIG_ARCH_EP7211=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_LV4T=y
|
||||
|
||||
@ -202,7 +202,6 @@ CONFIG_PXA_SSP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -198,7 +198,6 @@ CONFIG_EP93XX_EARLY_UART1=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
CONFIG_CPU_ABRT_EV4T=y
|
||||
|
||||
@ -203,7 +203,6 @@ CONFIG_PXA_HAVE_BOARD_IRQS=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -240,7 +240,6 @@ CONFIG_PLAT_PXA=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -95,7 +95,6 @@ CONFIG_ARCH_EBSA285=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA110=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -88,7 +88,6 @@ CONFIG_ARCH_FORTUNET=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_LV4T=y
|
||||
|
||||
@ -205,7 +205,6 @@ CONFIG_SA1100_H3600=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -206,7 +206,6 @@ CONFIG_PXA25x=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -87,7 +87,6 @@ CONFIG_CPU_H7201=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_LV4T=y
|
||||
|
||||
@ -91,7 +91,6 @@ CONFIG_CPU_H7202=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_LV4T=y
|
||||
|
||||
@ -103,7 +103,6 @@ CONFIG_SA1100_HACKKIT=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_SA1100=y
|
||||
CONFIG_CPU_32v4=y
|
||||
CONFIG_CPU_ABRT_EV4=y
|
||||
|
||||
@ -241,7 +241,6 @@ CONFIG_OMAP_ARM_195MHZ=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM925T=y
|
||||
CONFIG_CPU_ARM926T=y
|
||||
CONFIG_CPU_32v4T=y
|
||||
|
||||
@ -238,7 +238,6 @@ CONFIG_MACH_IGEP0020=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_32v6K=y
|
||||
CONFIG_CPU_V7=y
|
||||
CONFIG_CPU_32v7=y
|
||||
|
||||
@ -92,7 +92,6 @@ CONFIG_ARCH_INTEGRATOR_AP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_ARM720T=y
|
||||
CONFIG_CPU_ARM920T=y
|
||||
# CONFIG_CPU_ARM922T is not set
|
||||
|
||||
@ -163,7 +163,6 @@ CONFIG_PLAT_IOP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSC3=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -168,7 +168,6 @@ CONFIG_PLAT_IOP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -198,7 +198,6 @@ CONFIG_PLAT_IOP=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
@ -151,7 +151,6 @@ CONFIG_ARCH_IXDP2X01=y
|
||||
#
|
||||
# Processor Type
|
||||
#
|
||||
CONFIG_CPU_32=y
|
||||
CONFIG_CPU_XSCALE=y
|
||||
CONFIG_CPU_32v5=y
|
||||
CONFIG_CPU_ABRT_EV5T=y
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user