Merge commit 'v2.6.28-rc9' into next
This commit is contained in:
Dmitry Torokhov
Коммит
93b8eef1c0
2
.mailmap
2
.mailmap
|
|
@ -80,6 +80,8 @@ Nguyen Anh Quynh <aquynh@gmail.com>
|
|||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Rajesh Shah <rajesh.shah@intel.com>
|
||||
Ralf Baechle <ralf@linux-mips.org>
|
||||
|
|
|
|||
|
|
@ -42,14 +42,8 @@ IRQ.txt
|
|||
- description of what an IRQ is.
|
||||
ManagementStyle
|
||||
- how to (attempt to) manage kernel hackers.
|
||||
MSI-HOWTO.txt
|
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||
RCU/
|
||||
- directory with info on RCU (read-copy update).
|
||||
README.DAC960
|
||||
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
|
||||
README.cycladesZ
|
||||
- info on Cyclades-Z firmware loading.
|
||||
SAK.txt
|
||||
- info on Secure Attention Keys.
|
||||
SM501.txt
|
||||
|
|
@ -86,20 +80,16 @@ blackfin/
|
|||
- directory with documentation for the Blackfin arch.
|
||||
block/
|
||||
- info on the Block I/O (BIO) layer.
|
||||
blockdev/
|
||||
- info on block devices & drivers
|
||||
cachetlb.txt
|
||||
- describes the cache/TLB flushing interfaces Linux uses.
|
||||
cciss.txt
|
||||
- info, major/minor #'s for Compaq's SMART Array Controllers.
|
||||
cdrom/
|
||||
- directory with information on the CD-ROM drivers that Linux has.
|
||||
computone.txt
|
||||
- info on Computone Intelliport II/Plus Multiport Serial Driver.
|
||||
connector/
|
||||
- docs on the netlink based userspace<->kernel space communication mod.
|
||||
console/
|
||||
- documentation on Linux console drivers.
|
||||
cpqarray.txt
|
||||
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
|
||||
cpu-freq/
|
||||
- info on CPU frequency and voltage scaling.
|
||||
cpu-hotplug.txt
|
||||
|
|
@ -126,8 +116,6 @@ device-mapper/
|
|||
- directory with info on Device Mapper.
|
||||
devices.txt
|
||||
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
|
||||
digiepca.txt
|
||||
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
|
||||
dontdiff
|
||||
- file containing a list of files that should never be diff'ed.
|
||||
driver-model/
|
||||
|
|
@ -152,14 +140,10 @@ filesystems/
|
|||
- info on the vfs and the various filesystems that Linux supports.
|
||||
firmware_class/
|
||||
- request_firmware() hotplug interface info.
|
||||
floppy.txt
|
||||
- notes and driver options for the floppy disk driver.
|
||||
frv/
|
||||
- Fujitsu FR-V Linux documentation.
|
||||
gpio.txt
|
||||
- overview of GPIO (General Purpose Input/Output) access conventions.
|
||||
hayes-esp.txt
|
||||
- info on using the Hayes ESP serial driver.
|
||||
highuid.txt
|
||||
- notes on the change from 16 bit to 32 bit user/group IDs.
|
||||
timers/
|
||||
|
|
@ -172,7 +156,7 @@ i2c/
|
|||
- directory with info about the I2C bus/protocol (2 wire, kHz speed).
|
||||
i2o/
|
||||
- directory with info about the Linux I2O subsystem.
|
||||
i386/
|
||||
x86/i386/
|
||||
- directory with info about Linux on Intel 32 bit architecture.
|
||||
ia64/
|
||||
- directory with info about Linux on Intel 64 bit architecture.
|
||||
|
|
@ -186,8 +170,6 @@ io_ordering.txt
|
|||
- info on ordering I/O writes to memory-mapped addresses.
|
||||
ioctl/
|
||||
- directory with documents describing various IOCTL calls.
|
||||
ioctl-number.txt
|
||||
- how to implement and register device/driver ioctl calls.
|
||||
iostats.txt
|
||||
- info on I/O statistics Linux kernel provides.
|
||||
irqflags-tracing.txt
|
||||
|
|
@ -250,14 +232,10 @@ mips/
|
|||
- directory with info about Linux on MIPS architecture.
|
||||
mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
moxa-smartio
|
||||
- file with info on installing/using Moxa multiport serial driver.
|
||||
mutex-design.txt
|
||||
- info on the generic mutex subsystem.
|
||||
namespaces/
|
||||
- directory with various information about namespaces
|
||||
nbd.txt
|
||||
- info on a TCP implementation of a network block device.
|
||||
netlabel/
|
||||
- directory with information on the NetLabel subsystem.
|
||||
networking/
|
||||
|
|
@ -270,8 +248,6 @@ numastat.txt
|
|||
- info on how to read Numa policy hit/miss statistics in sysfs.
|
||||
oops-tracing.txt
|
||||
- how to decode those nasty internal kernel error dump messages.
|
||||
paride.txt
|
||||
- information about the parallel port IDE subsystem.
|
||||
parisc/
|
||||
- directory with info on using Linux on PA-RISC architecture.
|
||||
parport.txt
|
||||
|
|
@ -290,20 +266,16 @@ powerpc/
|
|||
- directory with info on using Linux with the PowerPC.
|
||||
preempt-locking.txt
|
||||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
prio_tree.txt
|
||||
- info on radix-priority-search-tree use for indexing vmas.
|
||||
ramdisk.txt
|
||||
- short guide on how to set up and use the RAM disk.
|
||||
rbtree.txt
|
||||
- info on what red-black trees are and what they are for.
|
||||
riscom8.txt
|
||||
- notes on using the RISCom/8 multi-port serial driver.
|
||||
robust-futex-ABI.txt
|
||||
- documentation of the robust futex ABI.
|
||||
robust-futexes.txt
|
||||
- a description of what robust futexes are.
|
||||
rocket.txt
|
||||
- info on the Comtrol RocketPort multiport serial driver.
|
||||
rt-mutex-design.txt
|
||||
- description of the RealTime mutex implementation design.
|
||||
rt-mutex.txt
|
||||
|
|
@ -332,8 +304,6 @@ sparc/
|
|||
- directory with info on using Linux on Sparc architecture.
|
||||
sparse.txt
|
||||
- info on how to obtain and use the sparse tool for typechecking.
|
||||
specialix.txt
|
||||
- info on hardware/driver for specialix IO8+ multiport serial card.
|
||||
spi/
|
||||
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
|
||||
spinlocks.txt
|
||||
|
|
@ -342,14 +312,10 @@ stable_api_nonsense.txt
|
|||
- info on why the kernel does not have a stable in-kernel api or abi.
|
||||
stable_kernel_rules.txt
|
||||
- rules and procedures for the -stable kernel releases.
|
||||
stallion.txt
|
||||
- info on using the Stallion multiport serial driver.
|
||||
svga.txt
|
||||
- short guide on selecting video modes at boot via VGA BIOS.
|
||||
sysfs-rules.txt
|
||||
- How not to use sysfs.
|
||||
sx.txt
|
||||
- info on the Specialix SX/SI multiport serial driver.
|
||||
sysctl/
|
||||
- directory with info on the /proc/sys/* files.
|
||||
sysrq.txt
|
||||
|
|
@ -358,8 +324,6 @@ telephony/
|
|||
- directory with info on telephony (e.g. voice over IP) support.
|
||||
time_interpolators.txt
|
||||
- info on time interpolators.
|
||||
tty.txt
|
||||
- guide to the locking policies of the tty layer.
|
||||
uml/
|
||||
- directory with information about User Mode Linux.
|
||||
unicode.txt
|
||||
|
|
@ -382,7 +346,7 @@ w1/
|
|||
- directory with documents regarding the 1-wire (w1) subsystem.
|
||||
watchdog/
|
||||
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
|
||||
x86_64/
|
||||
x86/x86_64/
|
||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
||||
zorro.txt
|
||||
- info on writing drivers for Zorro bus devices found on Amigas.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,88 @@
|
|||
What: /sys/class/c2port/
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/ directory will contain files and
|
||||
directories that will provide a unified interface to
|
||||
the C2 port interface.
|
||||
|
||||
What: /sys/class/c2port/c2portX
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/ directory is related to X-th
|
||||
C2 port into the system. Each directory will contain files to
|
||||
manage and control its C2 port.
|
||||
|
||||
What: /sys/class/c2port/c2portX/access
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/access file enable the access
|
||||
to the C2 port from the system. No commands can be sent
|
||||
till this entry is set to 0.
|
||||
|
||||
What: /sys/class/c2port/c2portX/dev_id
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/dev_id file show the device ID
|
||||
of the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_access
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_access file enable the
|
||||
access to the on-board flash of the connected micro.
|
||||
No commands can be sent till this entry is set to 0.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_block_size
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_block_size file show
|
||||
the on-board flash block size of the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_blocks_num
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_blocks_num file show
|
||||
the on-board flash blocks number of the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_data
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_data file export
|
||||
the content of the on-board flash of the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_erase
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_erase file execute
|
||||
the "erase" command on the on-board flash of the connected
|
||||
micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/flash_erase
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/flash_erase file show the
|
||||
on-board flash size of the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/reset
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/reset file execute a "reset"
|
||||
command on the connected micro.
|
||||
|
||||
What: /sys/class/c2port/c2portX/rev_id
|
||||
Date: October 2008
|
||||
Contact: Rodolfo Giometti <giometti@linux.it>
|
||||
Description:
|
||||
The /sys/class/c2port/c2portX/rev_id file show the revision ID
|
||||
of the connected micro.
|
||||
|
|
@ -89,7 +89,7 @@ Description:
|
|||
|
||||
error - an interrupt that can't be accounted for above.
|
||||
|
||||
invalid: it's either a wakeup GPE or a GPE/Fixed Event that
|
||||
invalid: it's either a GPE or a Fixed Event that
|
||||
doesn't have an event handler.
|
||||
|
||||
disable: the GPE/Fixed Event is valid but disabled.
|
||||
|
|
@ -117,30 +117,30 @@ Description:
|
|||
and other user space applications so that the machine won't shutdown
|
||||
when pressing the power button.
|
||||
# cat ff_pwr_btn
|
||||
0
|
||||
0 enabled
|
||||
# press the power button for 3 times;
|
||||
# cat ff_pwr_btn
|
||||
3
|
||||
3 enabled
|
||||
# echo disable > ff_pwr_btn
|
||||
# cat ff_pwr_btn
|
||||
disable
|
||||
3 disabled
|
||||
# press the power button for 3 times;
|
||||
# cat ff_pwr_btn
|
||||
disable
|
||||
3 disabled
|
||||
# echo enable > ff_pwr_btn
|
||||
# cat ff_pwr_btn
|
||||
4
|
||||
4 enabled
|
||||
/*
|
||||
* this is because the status bit is set even if the enable bit is cleared,
|
||||
* and it triggers an ACPI fixed event when the enable bit is set again
|
||||
*/
|
||||
# press the power button for 3 times;
|
||||
# cat ff_pwr_btn
|
||||
7
|
||||
7 enabled
|
||||
# echo disable > ff_pwr_btn
|
||||
# press the power button for 3 times;
|
||||
# echo clear > ff_pwr_btn /* clear the status bit */
|
||||
# echo disable > ff_pwr_btn
|
||||
# cat ff_pwr_btn
|
||||
7
|
||||
7 enabled
|
||||
|
||||
|
|
|
|||
|
|
@ -316,12 +316,10 @@ reduce current DMA mapping usage or delay and try again later).
|
|||
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
|
||||
int nents, int direction)
|
||||
|
||||
Maps a scatter gather list from the block layer.
|
||||
|
||||
Returns: the number of physical segments mapped (this may be shorter
|
||||
than <nents> passed in if the block layer determines that some
|
||||
elements of the scatter/gather list are physically adjacent and thus
|
||||
may be mapped with a single entry).
|
||||
than <nents> passed in if some elements of the scatter/gather list are
|
||||
physically or virtually adjacent and an IOMMU maps them with a single
|
||||
entry).
|
||||
|
||||
Please note that the sg cannot be mapped again if it has been mapped once.
|
||||
The mapping process is allowed to destroy information in the sg.
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ quiet_cmd_db2ps = PS $@
|
|||
%.ps : %.xml
|
||||
$(call cmd,db2ps)
|
||||
|
||||
quiet_cmd_db2pdf = PDF $@
|
||||
quiet_cmd_db2pdf = PDF $@
|
||||
cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
|
||||
%.pdf : %.xml
|
||||
$(call cmd,db2pdf)
|
||||
|
|
@ -148,7 +148,7 @@ build_main_index = rm -rf $(main_idx) && \
|
|||
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
|
||||
cat $(HTML) >> $(main_idx)
|
||||
|
||||
quiet_cmd_db2html = HTML $@
|
||||
quiet_cmd_db2html = HTML $@
|
||||
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
||||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
<surname>Cox</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>alan@redhat.com</email>
|
||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
<surname>Cox</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>alan@redhat.com</email>
|
||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
<surname>Cox</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>alan@redhat.com</email>
|
||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
<surname>Cox</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>alan@redhat.com</email>
|
||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ companies. If you sign purchase orders or you have any clue about the
|
|||
budget of your group, you're almost certainly not a kernel manager.
|
||||
These suggestions may or may not apply to you.
|
||||
|
||||
First off, I'd suggest buying "Seven Habits of Highly Successful
|
||||
First off, I'd suggest buying "Seven Habits of Highly Effective
|
||||
People", and NOT read it. Burn it, it's a great symbolic gesture.
|
||||
|
||||
(*) This document does so not so much by answering the question, but by
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
00-INDEX
|
||||
- this file
|
||||
MSI-HOWTO.txt
|
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||
PCI-DMA-mapping.txt
|
||||
- info for PCI drivers using DMA portably across all platforms
|
||||
PCIEBUS-HOWTO.txt
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
getdelays
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
ACPI Debug Output
|
||||
|
||||
|
||||
The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug
|
||||
output. This document describes how to use this facility.
|
||||
|
||||
Compile-time configuration
|
||||
--------------------------
|
||||
|
||||
ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config
|
||||
option is turned off, the debug messages are not even built into the
|
||||
kernel.
|
||||
|
||||
Boot- and run-time configuration
|
||||
--------------------------------
|
||||
|
||||
When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages
|
||||
you're interested in. At boot-time, use the acpi.debug_layer and
|
||||
acpi.debug_level kernel command line options. After boot, you can use the
|
||||
debug_layer and debug_level files in /sys/module/acpi/parameters/ to control
|
||||
the debug messages.
|
||||
|
||||
debug_layer (component)
|
||||
-----------------------
|
||||
|
||||
The "debug_layer" is a mask that selects components of interest, e.g., a
|
||||
specific driver or part of the ACPI interpreter. To build the debug_layer
|
||||
bitmask, look for the "#define _COMPONENT" in an ACPI source file.
|
||||
|
||||
You can set the debug_layer mask at boot-time using the acpi.debug_layer
|
||||
command line argument, and you can change it after boot by writing values
|
||||
to /sys/module/acpi/parameters/debug_layer.
|
||||
|
||||
The possible components are defined in include/acpi/acoutput.h and
|
||||
include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer
|
||||
shows the supported mask values, currently these:
|
||||
|
||||
ACPI_UTILITIES 0x00000001
|
||||
ACPI_HARDWARE 0x00000002
|
||||
ACPI_EVENTS 0x00000004
|
||||
ACPI_TABLES 0x00000008
|
||||
ACPI_NAMESPACE 0x00000010
|
||||
ACPI_PARSER 0x00000020
|
||||
ACPI_DISPATCHER 0x00000040
|
||||
ACPI_EXECUTER 0x00000080
|
||||
ACPI_RESOURCES 0x00000100
|
||||
ACPI_CA_DEBUGGER 0x00000200
|
||||
ACPI_OS_SERVICES 0x00000400
|
||||
ACPI_CA_DISASSEMBLER 0x00000800
|
||||
ACPI_COMPILER 0x00001000
|
||||
ACPI_TOOLS 0x00002000
|
||||
ACPI_BUS_COMPONENT 0x00010000
|
||||
ACPI_AC_COMPONENT 0x00020000
|
||||
ACPI_BATTERY_COMPONENT 0x00040000
|
||||
ACPI_BUTTON_COMPONENT 0x00080000
|
||||
ACPI_SBS_COMPONENT 0x00100000
|
||||
ACPI_FAN_COMPONENT 0x00200000
|
||||
ACPI_PCI_COMPONENT 0x00400000
|
||||
ACPI_POWER_COMPONENT 0x00800000
|
||||
ACPI_CONTAINER_COMPONENT 0x01000000
|
||||
ACPI_SYSTEM_COMPONENT 0x02000000
|
||||
ACPI_THERMAL_COMPONENT 0x04000000
|
||||
ACPI_MEMORY_DEVICE_COMPONENT 0x08000000
|
||||
ACPI_VIDEO_COMPONENT 0x10000000
|
||||
ACPI_PROCESSOR_COMPONENT 0x20000000
|
||||
|
||||
debug_level
|
||||
-----------
|
||||
|
||||
The "debug_level" is a mask that selects different types of messages, e.g.,
|
||||
those related to initialization, method execution, informational messages, etc.
|
||||
To build debug_level, look at the level specified in an ACPI_DEBUG_PRINT()
|
||||
statement.
|
||||
|
||||
The ACPI interpreter uses several different levels, but the Linux
|
||||
ACPI core and ACPI drivers generally only use ACPI_LV_INFO.
|
||||
|
||||
You can set the debug_level mask at boot-time using the acpi.debug_level
|
||||
command line argument, and you can change it after boot by writing values
|
||||
to /sys/module/acpi/parameters/debug_level.
|
||||
|
||||
The possible levels are defined in include/acpi/acoutput.h. Reading
|
||||
/sys/module/acpi/parameters/debug_level shows the supported mask values,
|
||||
currently these:
|
||||
|
||||
ACPI_LV_INIT 0x00000001
|
||||
ACPI_LV_DEBUG_OBJECT 0x00000002
|
||||
ACPI_LV_INFO 0x00000004
|
||||
ACPI_LV_INIT_NAMES 0x00000020
|
||||
ACPI_LV_PARSE 0x00000040
|
||||
ACPI_LV_LOAD 0x00000080
|
||||
ACPI_LV_DISPATCH 0x00000100
|
||||
ACPI_LV_EXEC 0x00000200
|
||||
ACPI_LV_NAMES 0x00000400
|
||||
ACPI_LV_OPREGION 0x00000800
|
||||
ACPI_LV_BFIELD 0x00001000
|
||||
ACPI_LV_TABLES 0x00002000
|
||||
ACPI_LV_VALUES 0x00004000
|
||||
ACPI_LV_OBJECTS 0x00008000
|
||||
ACPI_LV_RESOURCES 0x00010000
|
||||
ACPI_LV_USER_REQUESTS 0x00020000
|
||||
ACPI_LV_PACKAGE 0x00040000
|
||||
ACPI_LV_ALLOCATIONS 0x00100000
|
||||
ACPI_LV_FUNCTIONS 0x00200000
|
||||
ACPI_LV_OPTIMIZATIONS 0x00400000
|
||||
ACPI_LV_MUTEX 0x01000000
|
||||
ACPI_LV_THREADS 0x02000000
|
||||
ACPI_LV_IO 0x04000000
|
||||
ACPI_LV_INTERRUPTS 0x08000000
|
||||
ACPI_LV_AML_DISASSEMBLE 0x10000000
|
||||
ACPI_LV_VERBOSE_INFO 0x20000000
|
||||
ACPI_LV_FULL_TABLES 0x40000000
|
||||
ACPI_LV_EVENTS 0x80000000
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
For example, drivers/acpi/bus.c contains this:
|
||||
|
||||
#define _COMPONENT ACPI_BUS_COMPONENT
|
||||
...
|
||||
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n"));
|
||||
|
||||
To turn on this message, set the ACPI_BUS_COMPONENT bit in acpi.debug_layer
|
||||
and the ACPI_LV_INFO bit in acpi.debug_level. (The ACPI_DEBUG_PRINT
|
||||
statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO
|
||||
definition.)
|
||||
|
||||
Enable all AML "Debug" output (stores to the Debug object while interpreting
|
||||
AML) during boot:
|
||||
|
||||
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
|
||||
|
||||
Enable PCI and PCI interrupt routing debug messages:
|
||||
|
||||
acpi.debug_layer=0x400000 acpi.debug_level=0x4
|
||||
|
||||
Enable all ACPI hardware-related messages:
|
||||
|
||||
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
|
||||
|
||||
Enable all ACPI_DB_INFO messages after boot:
|
||||
|
||||
# echo 0x4 > /sys/module/acpi/parameters/debug_level
|
||||
|
||||
Show all valid component values:
|
||||
|
||||
# cat /sys/module/acpi/parameters/debug_layer
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
Empeg, Ltd's Empeg MP3 Car Audio Player
|
||||
|
||||
The initial design is to go in your car, but you can use it at home, on a
|
||||
boat... almost anywhere. The principle is to store CD-quality music using
|
||||
MPEG technology onto a hard disk in the unit, and use the power of the
|
||||
embedded computer to serve up the music you want.
|
||||
|
||||
For more details, see:
|
||||
|
||||
http://www.empeg.com
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
Infra-red driver documentation.
|
||||
|
||||
Mike Crowe <mac@empeg.com>
|
||||
(C) Empeg Ltd 1999
|
||||
|
||||
Not a lot here yet :-)
|
||||
|
||||
The Kenwood KCA-R6A remote control generates a sequence like the following:
|
||||
|
||||
Go low for approx 16T (Around 9000us)
|
||||
Go high for approx 8T (Around 4000us)
|
||||
Go low for less than 2T (Around 750us)
|
||||
|
||||
For each of the 32 bits
|
||||
Go high for more than 2T (Around 1500us) == 1
|
||||
Go high for less than T (Around 400us) == 0
|
||||
Go low for less than 2T (Around 750us)
|
||||
|
||||
Rather than repeat a signal when the button is held down certain buttons
|
||||
generate the following code to indicate repetition.
|
||||
|
||||
Go low for approx 16T
|
||||
Go high for approx 4T
|
||||
Go low for less than 2T
|
||||
|
||||
(By removing the <2T from the start of the sequence and placing at the end
|
||||
it can be considered a stop bit but I found it easier to deal with it at
|
||||
the start).
|
||||
|
||||
The 32 bits are encoded as XxYy where x and y are the actual data values
|
||||
while X and Y are the logical inverses of the associated data values. Using
|
||||
LSB first yields sensible codes for the numbers.
|
||||
|
||||
All codes are of the form b9xx
|
||||
|
||||
The numeric keys generate the code 0x where x is the number pressed.
|
||||
|
||||
Tuner 1c
|
||||
Tape 1d
|
||||
CD 1e
|
||||
CD-MD-CH 1f
|
||||
Track- 0a
|
||||
Track+ 0b
|
||||
Rewind 0c
|
||||
FF 0d
|
||||
DNPP 5e
|
||||
Play/Pause 0e
|
||||
Vol+ 14
|
||||
Vol- 15
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
#!/bin/sh
|
||||
mknod /dev/display c 244 0
|
||||
mknod /dev/ir c 242 0
|
||||
mknod /dev/usb0 c 243 0
|
||||
mknod /dev/audio c 245 4
|
||||
mknod /dev/dsp c 245 3
|
||||
mknod /dev/mixer c 245 0
|
||||
mknod /dev/empeg_state c 246 0
|
||||
mknod /dev/radio0 c 81 64
|
||||
ln -sf radio0 radio
|
||||
ln -sf usb0 usb
|
||||
|
|
@ -24,7 +24,7 @@ real bad - it changes the behaviour of all unaligned instructions in user
|
|||
space, and might cause programs to fail unexpectedly.
|
||||
|
||||
To change the alignment trap behavior, simply echo a number into
|
||||
/proc/sys/debug/alignment. The number is made up from various bits:
|
||||
/proc/cpu/alignment. The number is made up from various bits:
|
||||
|
||||
bit behavior when set
|
||||
--- -----------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
cfag12864b-example
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
00-INDEX
|
||||
- this file
|
||||
README.DAC960
|
||||
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
|
||||
cciss.txt
|
||||
- info, major/minor #'s for Compaq's SMART Array Controllers.
|
||||
cpqarray.txt
|
||||
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
|
||||
floppy.txt
|
||||
- notes and driver options for the floppy disk driver.
|
||||
nbd.txt
|
||||
- info on a TCP implementation of a network block device.
|
||||
paride.txt
|
||||
- information about the parallel port IDE subsystem.
|
||||
ramdisk.txt
|
||||
- short guide on how to set up and use the RAM disk.
|
||||
|
|
@ -21,11 +21,14 @@ This driver is known to work with the following cards:
|
|||
* SA E200
|
||||
* SA E200i
|
||||
* SA E500
|
||||
* SA P700m
|
||||
* SA P212
|
||||
* SA P410
|
||||
* SA P410i
|
||||
* SA P411
|
||||
* SA P812
|
||||
* SA P712m
|
||||
* SA P711m
|
||||
|
||||
Detecting drive failures:
|
||||
-------------------------
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
C2 port support
|
||||
---------------
|
||||
|
||||
(C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
This driver implements the support for Linux of Silicon Labs (Silabs)
|
||||
C2 Interface used for in-system programming of micro controllers.
|
||||
|
||||
By using this driver you can reprogram the in-system flash without EC2
|
||||
or EC3 debug adapter. This solution is also useful in those systems
|
||||
where the micro controller is connected via special GPIOs pins.
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
The C2 Interface main references are at (http://www.silabs.com)
|
||||
Silicon Laboratories site], see:
|
||||
|
||||
- AN127: FLASH Programming via the C2 Interface at
|
||||
http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/Small_Form_Factor/en/an127.pdf, and
|
||||
|
||||
- C2 Specification at
|
||||
http://www.silabs.com/public/documents/tpub_doc/spec/Microcontrollers/en/C2spec.pdf,
|
||||
|
||||
however it implements a two wire serial communication protocol (bit
|
||||
banging) designed to enable in-system programming, debugging, and
|
||||
boundary-scan testing on low pin-count Silicon Labs devices. Currently
|
||||
this code supports only flash programming but extensions are easy to
|
||||
add.
|
||||
|
||||
Using the driver
|
||||
----------------
|
||||
|
||||
Once the driver is loaded you can use sysfs support to get C2port's
|
||||
info or read/write in-system flash.
|
||||
|
||||
# ls /sys/class/c2port/c2port0/
|
||||
access flash_block_size flash_erase rev_id
|
||||
dev_id flash_blocks_num flash_size subsystem/
|
||||
flash_access flash_data reset uevent
|
||||
|
||||
Initially the C2port access is disabled since you hardware may have
|
||||
such lines multiplexed with other devices so, to get access to the
|
||||
C2port, you need the command:
|
||||
|
||||
# echo 1 > /sys/class/c2port/c2port0/access
|
||||
|
||||
after that you should read the device ID and revision ID of the
|
||||
connected micro controller:
|
||||
|
||||
# cat /sys/class/c2port/c2port0/dev_id
|
||||
8
|
||||
# cat /sys/class/c2port/c2port0/rev_id
|
||||
1
|
||||
|
||||
However, for security reasons, the in-system flash access in not
|
||||
enabled yet, to do so you need the command:
|
||||
|
||||
# echo 1 > /sys/class/c2port/c2port0/flash_access
|
||||
|
||||
After that you can read the whole flash:
|
||||
|
||||
# cat /sys/class/c2port/c2port0/flash_data > image
|
||||
|
||||
erase it:
|
||||
|
||||
# echo 1 > /sys/class/c2port/c2port0/flash_erase
|
||||
|
||||
and write it:
|
||||
|
||||
# cat image > /sys/class/c2port/c2port0/flash_data
|
||||
|
||||
after writing you have to reset the device to execute the new code:
|
||||
|
||||
# echo 1 > /sys/class/c2port/c2port0/reset
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
The cgroup freezer is useful to batch job management system which start
|
||||
The cgroup freezer is useful to batch job management system which start
|
||||
and stop sets of tasks in order to schedule the resources of a machine
|
||||
according to the desires of a system administrator. This sort of program
|
||||
is often used on HPC clusters to schedule access to the cluster as a
|
||||
|
|
@ -6,7 +6,7 @@ whole. The cgroup freezer uses cgroups to describe the set of tasks to
|
|||
be started/stopped by the batch job management system. It also provides
|
||||
a means to start and stop the tasks composing the job.
|
||||
|
||||
The cgroup freezer will also be useful for checkpointing running groups
|
||||
The cgroup freezer will also be useful for checkpointing running groups
|
||||
of tasks. The freezer allows the checkpoint code to obtain a consistent
|
||||
image of the tasks by attempting to force the tasks in a cgroup into a
|
||||
quiescent state. Once the tasks are quiescent another task can
|
||||
|
|
@ -16,7 +16,7 @@ recoverable error occur. This also allows the checkpointed tasks to be
|
|||
migrated between nodes in a cluster by copying the gathered information
|
||||
to another node and restarting the tasks there.
|
||||
|
||||
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
|
||||
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
|
||||
and resuming tasks in userspace. Both of these signals are observable
|
||||
from within the tasks we wish to freeze. While SIGSTOP cannot be caught,
|
||||
blocked, or ignored it can be seen by waiting or ptracing parent tasks.
|
||||
|
|
@ -37,26 +37,29 @@ demonstrate this problem using nested bash shells:
|
|||
|
||||
<at this point 16990 exits and causes 16644 to exit too>
|
||||
|
||||
This happens because bash can observe both signals and choose how it
|
||||
This happens because bash can observe both signals and choose how it
|
||||
responds to them.
|
||||
|
||||
Another example of a program which catches and responds to these
|
||||
Another example of a program which catches and responds to these
|
||||
signals is gdb. In fact any program designed to use ptrace is likely to
|
||||
have a problem with this method of stopping and resuming tasks.
|
||||
|
||||
In contrast, the cgroup freezer uses the kernel freezer code to
|
||||
In contrast, the cgroup freezer uses the kernel freezer code to
|
||||
prevent the freeze/unfreeze cycle from becoming visible to the tasks
|
||||
being frozen. This allows the bash example above and gdb to run as
|
||||
expected.
|
||||
|
||||
The freezer subsystem in the container filesystem defines a file named
|
||||
The freezer subsystem in the container filesystem defines a file named
|
||||
freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the
|
||||
cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup.
|
||||
Reading will return the current state.
|
||||
|
||||
Note freezer.state doesn't exist in root cgroup, which means root cgroup
|
||||
is non-freezable.
|
||||
|
||||
* Examples of usage :
|
||||
|
||||
# mkdir /containers/freezer
|
||||
# mkdir /containers
|
||||
# mount -t cgroup -ofreezer freezer /containers
|
||||
# mkdir /containers/0
|
||||
# echo $some_pid > /containers/0/tasks
|
||||
|
|
@ -94,6 +97,6 @@ things happens:
|
|||
the freezer.state file
|
||||
2) Userspace retries the freezing operation by writing "FROZEN" to
|
||||
the freezer.state file (writing "FREEZING" is not legal
|
||||
and returns EIO)
|
||||
and returns EINVAL)
|
||||
3) The tasks that blocked the cgroup from entering the "FROZEN"
|
||||
state disappear from the cgroup's set of tasks.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
ucon
|
||||
|
|
@ -23,6 +23,7 @@ Contents:
|
|||
1.3 sparc64
|
||||
1.4 ppc
|
||||
1.5 SuperH
|
||||
1.6 Blackfin
|
||||
|
||||
2. "Policy" / "Governor"?
|
||||
2.1 Policy
|
||||
|
|
@ -97,6 +98,17 @@ The following SuperH processors are supported by cpufreq:
|
|||
SH-3
|
||||
SH-4
|
||||
|
||||
1.6 Blackfin
|
||||
------------
|
||||
|
||||
The following Blackfin processors are supported by cpufreq:
|
||||
|
||||
BF522, BF523, BF524, BF525, BF526, BF527, Rev 0.1 or higher
|
||||
BF531, BF532, BF533, Rev 0.3 or higher
|
||||
BF534, BF536, BF537, Rev 0.2 or higher
|
||||
BF561, Rev 0.3 or higher
|
||||
BF542, BF544, BF547, BF548, BF549, Rev 0.1 or higher
|
||||
|
||||
|
||||
2. "Policy" / "Governor" ?
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -213,4 +213,29 @@ TkRat (GUI)
|
|||
|
||||
Works. Use "Insert file..." or external editor.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Gmail (Web GUI)
|
||||
|
||||
If you just have to use Gmail to send patches, it CAN be made to work. It
|
||||
requires a bit of external help, though.
|
||||
|
||||
The first problem is that Gmail converts tabs to spaces. This will
|
||||
totally break your patches. To prevent this, you have to use a different
|
||||
editor. There is a firefox extension called "ViewSourceWith"
|
||||
(https://addons.mozilla.org/en-US/firefox/addon/394) which allows you to
|
||||
edit any text box in the editor of your choice. Configure it to launch
|
||||
your favorite editor. When you want to send a patch, use this technique.
|
||||
Once you have crafted your messsage + patch, save and exit the editor,
|
||||
which should reload the Gmail edit box. GMAIL WILL PRESERVE THE TABS.
|
||||
Hoorah. Apparently you can cut-n-paste literal tabs, but Gmail will
|
||||
convert those to spaces upon sending!
|
||||
|
||||
The second problem is that Gmail converts tabs to spaces on replies. If
|
||||
you reply to a patch, don't expect to be able to apply it as a patch.
|
||||
|
||||
The last problem is that Gmail will base64-encode any message that has a
|
||||
non-ASCII character. That includes things like European names. Be aware.
|
||||
|
||||
Gmail is not convenient for lkml patches, but CAN be made to work.
|
||||
|
||||
###
|
||||
|
|
|
|||
|
|
@ -56,30 +56,6 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: old tuner-3036 i2c driver
|
||||
When: 2.6.28
|
||||
Why: This driver is for VERY old i2c-over-parallel port teletext receiver
|
||||
boxes. Rather then spending effort on converting this driver to V4L2,
|
||||
and since it is extremely unlikely that anyone still uses one of these
|
||||
devices, it was decided to drop it.
|
||||
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: V4L2 dpc7146 driver
|
||||
When: 2.6.28
|
||||
Why: Old driver for the dpc7146 demonstration board that is no longer
|
||||
relevant. The last time this was tested on actual hardware was
|
||||
probably around 2002. Since this is a driver for a demonstration
|
||||
board the decision was made to remove it rather than spending a
|
||||
lot of effort continually updating this driver to stay in sync
|
||||
with the latest internal V4L2 or I2C API.
|
||||
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||
When: November 2005
|
||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
||||
|
|
|
|||
|
|
@ -161,8 +161,12 @@ prototypes:
|
|||
int (*set_page_dirty)(struct page *page);
|
||||
int (*readpages)(struct file *filp, struct address_space *mapping,
|
||||
struct list_head *pages, unsigned nr_pages);
|
||||
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
|
||||
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
|
||||
int (*write_begin)(struct file *, struct address_space *mapping,
|
||||
loff_t pos, unsigned len, unsigned flags,
|
||||
struct page **pagep, void **fsdata);
|
||||
int (*write_end)(struct file *, struct address_space *mapping,
|
||||
loff_t pos, unsigned len, unsigned copied,
|
||||
struct page *page, void *fsdata);
|
||||
sector_t (*bmap)(struct address_space *, sector_t);
|
||||
int (*invalidatepage) (struct page *, unsigned long);
|
||||
int (*releasepage) (struct page *, int);
|
||||
|
|
@ -180,8 +184,6 @@ sync_page: no maybe
|
|||
writepages: no
|
||||
set_page_dirty no no
|
||||
readpages: no
|
||||
prepare_write: no yes yes
|
||||
commit_write: no yes yes
|
||||
write_begin: no locks the page yes
|
||||
write_end: no yes, unlocks yes
|
||||
perform_write: no n/a yes
|
||||
|
|
@ -191,7 +193,7 @@ releasepage: no yes
|
|||
direct_IO: no
|
||||
launder_page: no yes
|
||||
|
||||
->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
|
||||
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
|
||||
may be called from the request handler (/dev/loop).
|
||||
|
||||
->readpage() unlocks the page, either synchronously or via I/O
|
||||
|
|
|
|||
|
|
@ -28,10 +28,7 @@ Manish Singh <manish.singh@oracle.com>
|
|||
Caveats
|
||||
=======
|
||||
Features which OCFS2 does not support yet:
|
||||
- extended attributes
|
||||
- quotas
|
||||
- cluster aware flock
|
||||
- cluster aware lockf
|
||||
- Directory change notification (F_NOTIFY)
|
||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||
- POSIX ACLs
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ Table of Contents
|
|||
2.14 /proc/<pid>/io - Display the IO accounting fields
|
||||
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
|
||||
2.16 /proc/<pid>/mountinfo - Information about mounts
|
||||
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Preface
|
||||
|
|
@ -2483,4 +2484,30 @@ For more information on mount propagation see:
|
|||
|
||||
Documentation/filesystems/sharedsubtree.txt
|
||||
|
||||
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
|
||||
--------------------------------------------------------
|
||||
|
||||
This directory contains configuration options for the epoll(7) interface.
|
||||
|
||||
max_user_instances
|
||||
------------------
|
||||
|
||||
This is the maximum number of epoll file descriptors that a single user can
|
||||
have open at a given time. The default value is 128, and should be enough
|
||||
for normal users.
|
||||
|
||||
max_user_watches
|
||||
----------------
|
||||
|
||||
Every epoll file descriptor can store a number of files to be monitored
|
||||
for event readiness. Each one of these monitored files constitutes a "watch".
|
||||
This configuration option sets the maximum number of "watches" that are
|
||||
allowed for each user.
|
||||
Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes
|
||||
on a 64bit one.
|
||||
The current default value for max_user_watches is the 1/32 of the available
|
||||
low memory, divided for the "watch" cost in bytes.
|
||||
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -130,12 +130,12 @@ The 2.6 kernel build process always creates a gzipped cpio format initramfs
|
|||
archive and links it into the resulting kernel binary. By default, this
|
||||
archive is empty (consuming 134 bytes on x86).
|
||||
|
||||
The config option CONFIG_INITRAMFS_SOURCE (for some reason buried under
|
||||
devices->block devices in menuconfig, and living in usr/Kconfig) can be used
|
||||
to specify a source for the initramfs archive, which will automatically be
|
||||
incorporated into the resulting binary. This option can point to an existing
|
||||
gzipped cpio archive, a directory containing files to be archived, or a text
|
||||
file specification such as the following example:
|
||||
The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
|
||||
and living in usr/Kconfig) can be used to specify a source for the
|
||||
initramfs archive, which will automatically be incorporated into the
|
||||
resulting binary. This option can point to an existing gzipped cpio
|
||||
archive, a directory containing files to be archived, or a text file
|
||||
specification such as the following example:
|
||||
|
||||
dir /dev 755 0 0
|
||||
nod /dev/console 644 0 0 c 5 1
|
||||
|
|
|
|||
|
|
@ -8,6 +8,12 @@ if you want to format from within Linux.
|
|||
|
||||
VFAT MOUNT OPTIONS
|
||||
----------------------------------------------------------------------
|
||||
uid=### -- Set the owner of all files on this filesystem.
|
||||
The default is the uid of current process.
|
||||
|
||||
gid=### -- Set the group of all files on this filesystem.
|
||||
The default is the gid of current process.
|
||||
|
||||
umask=### -- The permission mask (for files and directories, see umask(1)).
|
||||
The default is the umask of current process.
|
||||
|
||||
|
|
@ -36,7 +42,7 @@ codepage=### -- Sets the codepage number for converting to shortname
|
|||
characters on FAT filesystem.
|
||||
By default, FAT_DEFAULT_CODEPAGE setting is used.
|
||||
|
||||
iocharset=name -- Character set to use for converting between the
|
||||
iocharset=<name> -- Character set to use for converting between the
|
||||
encoding is used for user visible filename and 16 bit
|
||||
Unicode characters. Long filenames are stored on disk
|
||||
in Unicode format, but Unix for the most part doesn't
|
||||
|
|
@ -86,6 +92,8 @@ check=s|r|n -- Case sensitivity checking setting.
|
|||
r: relaxed, case insensitive
|
||||
n: normal, default setting, currently case insensitive
|
||||
|
||||
nocase -- This was deprecated for vfat. Use shortname=win95 instead.
|
||||
|
||||
shortname=lower|win95|winnt|mixed
|
||||
-- Shortname display/create setting.
|
||||
lower: convert to lowercase for display,
|
||||
|
|
@ -99,11 +107,31 @@ shortname=lower|win95|winnt|mixed
|
|||
tz=UTC -- Interpret timestamps as UTC rather than local time.
|
||||
This option disables the conversion of timestamps
|
||||
between local time (as used by Windows on FAT) and UTC
|
||||
(which Linux uses internally). This is particuluarly
|
||||
(which Linux uses internally). This is particularly
|
||||
useful when mounting devices (like digital cameras)
|
||||
that are set to UTC in order to avoid the pitfalls of
|
||||
local time.
|
||||
|
||||
showexec -- If set, the execute permission bits of the file will be
|
||||
allowed only if the extension part of the name is .EXE,
|
||||
.COM, or .BAT. Not set by default.
|
||||
|
||||
debug -- Can be set, but unused by the current implementation.
|
||||
|
||||
sys_immutable -- If set, ATTR_SYS attribute on FAT is handled as
|
||||
IMMUTABLE flag on Linux. Not set by default.
|
||||
|
||||
flush -- If set, the filesystem will try to flush to disk more
|
||||
early than normal. Not set by default.
|
||||
|
||||
rodir -- FAT has the ATTR_RO (read-only) attribute. But on Windows,
|
||||
the ATTR_RO of the directory will be just ignored actually,
|
||||
and is used by only applications as flag. E.g. it's setted
|
||||
for the customized folder.
|
||||
|
||||
If you want to use ATTR_RO as read-only flag even for
|
||||
the directory, set this option.
|
||||
|
||||
<bool>: 0,1,yes,no,true,false
|
||||
|
||||
TODO
|
||||
|
|
|
|||
|
|
@ -492,7 +492,7 @@ written-back to storage typically in whole pages, however the
|
|||
address_space has finer control of write sizes.
|
||||
|
||||
The read process essentially only requires 'readpage'. The write
|
||||
process is more complicated and uses prepare_write/commit_write or
|
||||
process is more complicated and uses write_begin/write_end or
|
||||
set_page_dirty to write data into the address_space, and writepage,
|
||||
sync_page, and writepages to writeback data to storage.
|
||||
|
||||
|
|
@ -521,8 +521,6 @@ struct address_space_operations {
|
|||
int (*set_page_dirty)(struct page *page);
|
||||
int (*readpages)(struct file *filp, struct address_space *mapping,
|
||||
struct list_head *pages, unsigned nr_pages);
|
||||
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
|
||||
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
|
||||
int (*write_begin)(struct file *, struct address_space *mapping,
|
||||
loff_t pos, unsigned len, unsigned flags,
|
||||
struct page **pagep, void **fsdata);
|
||||
|
|
@ -598,37 +596,7 @@ struct address_space_operations {
|
|||
readpages is only used for read-ahead, so read errors are
|
||||
ignored. If anything goes wrong, feel free to give up.
|
||||
|
||||
prepare_write: called by the generic write path in VM to set up a write
|
||||
request for a page. This indicates to the address space that
|
||||
the given range of bytes is about to be written. The
|
||||
address_space should check that the write will be able to
|
||||
complete, by allocating space if necessary and doing any other
|
||||
internal housekeeping. If the write will update parts of
|
||||
any basic-blocks on storage, then those blocks should be
|
||||
pre-read (if they haven't been read already) so that the
|
||||
updated blocks can be written out properly.
|
||||
The page will be locked.
|
||||
|
||||
Note: the page _must not_ be marked uptodate in this function
|
||||
(or anywhere else) unless it actually is uptodate right now. As
|
||||
soon as a page is marked uptodate, it is possible for a concurrent
|
||||
read(2) to copy it to userspace.
|
||||
|
||||
commit_write: If prepare_write succeeds, new data will be copied
|
||||
into the page and then commit_write will be called. It will
|
||||
typically update the size of the file (if appropriate) and
|
||||
mark the inode as dirty, and do any other related housekeeping
|
||||
operations. It should avoid returning an error if possible -
|
||||
errors should have been handled by prepare_write.
|
||||
|
||||
write_begin: This is intended as a replacement for prepare_write. The
|
||||
key differences being that:
|
||||
- it returns a locked page (in *pagep) rather than being
|
||||
given a pre locked page;
|
||||
- it must be able to cope with short writes (where the
|
||||
length passed to write_begin is greater than the number
|
||||
of bytes copied into the page).
|
||||
|
||||
write_begin:
|
||||
Called by the generic buffered write code to ask the filesystem to
|
||||
prepare to write len bytes at the given offset in the file. The
|
||||
address_space should check that the write will be able to complete,
|
||||
|
|
@ -640,6 +608,9 @@ struct address_space_operations {
|
|||
The filesystem must return the locked pagecache page for the specified
|
||||
offset, in *pagep, for the caller to write into.
|
||||
|
||||
It must be able to cope with short writes (where the length passed to
|
||||
write_begin is greater than the number of bytes copied into the page).
|
||||
|
||||
flags is a field for AOP_FLAG_xxx flags, described in
|
||||
include/linux/fs.h.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,10 +39,11 @@ The block device operation is optional, these block devices support it as of
|
|||
today:
|
||||
- dcssblk: s390 dcss block device driver
|
||||
|
||||
An address space operation named get_xip_page is used to retrieve reference
|
||||
to a struct page. To address the target page, a reference to an address_space,
|
||||
and a sector number is provided. A 3rd argument indicates whether the
|
||||
function should allocate blocks if needed.
|
||||
An address space operation named get_xip_mem is used to retrieve references
|
||||
to a page frame number and a kernel address. To obtain these values a reference
|
||||
to an address_space is provided. This function assigns values to the kmem and
|
||||
pfn parameters. The third argument indicates whether the function should allocate
|
||||
blocks if needed.
|
||||
|
||||
This address space operation is mutually exclusive with readpage&writepage that
|
||||
do page cache read/write operations.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Copyright 2008 Red Hat Inc.
|
|||
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
|
||||
John Kacur, and David Teigland.
|
||||
|
||||
Written for: 2.6.27-rc1
|
||||
Written for: 2.6.28-rc2
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
|
@ -50,26 +50,26 @@ of ftrace. Here is a list of some of the key files:
|
|||
|
||||
Note: all time values are in microseconds.
|
||||
|
||||
current_tracer : This is used to set or display the current tracer
|
||||
current_tracer: This is used to set or display the current tracer
|
||||
that is configured.
|
||||
|
||||
available_tracers : This holds the different types of tracers that
|
||||
available_tracers: This holds the different types of tracers that
|
||||
have been compiled into the kernel. The tracers
|
||||
listed here can be configured by echoing their name
|
||||
into current_tracer.
|
||||
|
||||
tracing_enabled : This sets or displays whether the current_tracer
|
||||
tracing_enabled: This sets or displays whether the current_tracer
|
||||
is activated and tracing or not. Echo 0 into this
|
||||
file to disable the tracer or 1 to enable it.
|
||||
|
||||
trace : This file holds the output of the trace in a human readable
|
||||
trace: This file holds the output of the trace in a human readable
|
||||
format (described below).
|
||||
|
||||
latency_trace : This file shows the same trace but the information
|
||||
latency_trace: This file shows the same trace but the information
|
||||
is organized more to display possible latencies
|
||||
in the system (described below).
|
||||
|
||||
trace_pipe : The output is the same as the "trace" file but this
|
||||
trace_pipe: The output is the same as the "trace" file but this
|
||||
file is meant to be streamed with live tracing.
|
||||
Reads from this file will block until new data
|
||||
is retrieved. Unlike the "trace" and "latency_trace"
|
||||
|
|
@ -82,11 +82,11 @@ of ftrace. Here is a list of some of the key files:
|
|||
tracer is not adding more data, they will display
|
||||
the same information every time they are read.
|
||||
|
||||
iter_ctrl : This file lets the user control the amount of data
|
||||
iter_ctrl: This file lets the user control the amount of data
|
||||
that is displayed in one of the above output
|
||||
files.
|
||||
|
||||
trace_max_latency : Some of the tracers record the max latency.
|
||||
trace_max_latency: Some of the tracers record the max latency.
|
||||
For example, the time interrupts are disabled.
|
||||
This time is saved in this file. The max trace
|
||||
will also be stored, and displayed by either
|
||||
|
|
@ -94,29 +94,26 @@ of ftrace. Here is a list of some of the key files:
|
|||
only be recorded if the latency is greater than
|
||||
the value in this file. (in microseconds)
|
||||
|
||||
trace_entries : This sets or displays the number of trace
|
||||
entries each CPU buffer can hold. The tracer buffers
|
||||
are the same size for each CPU. The displayed number
|
||||
is the size of the CPU buffer and not total size. The
|
||||
trace_entries: This sets or displays the number of bytes each CPU
|
||||
buffer can hold. The tracer buffers are the same size
|
||||
for each CPU. The displayed number is the size of the
|
||||
CPU buffer and not total size of all buffers. The
|
||||
trace buffers are allocated in pages (blocks of memory
|
||||
that the kernel uses for allocation, usually 4 KB in size).
|
||||
Since each entry is smaller than a page, if the last
|
||||
allocated page has room for more entries than were
|
||||
requested, the rest of the page is used to allocate
|
||||
entries.
|
||||
If the last page allocated has room for more bytes
|
||||
than requested, the rest of the page will be used,
|
||||
making the actual allocation bigger than requested.
|
||||
(Note, the size may not be a multiple of the page size due
|
||||
to buffer managment overhead.)
|
||||
|
||||
This can only be updated when the current_tracer
|
||||
is set to "none".
|
||||
is set to "nop".
|
||||
|
||||
NOTE: It is planned on changing the allocated buffers
|
||||
from being the number of possible CPUS to
|
||||
the number of online CPUS.
|
||||
|
||||
tracing_cpumask : This is a mask that lets the user only trace
|
||||
tracing_cpumask: This is a mask that lets the user only trace
|
||||
on specified CPUS. The format is a hex string
|
||||
representing the CPUS.
|
||||
|
||||
set_ftrace_filter : When dynamic ftrace is configured in (see the
|
||||
set_ftrace_filter: When dynamic ftrace is configured in (see the
|
||||
section below "dynamic ftrace"), the code is dynamically
|
||||
modified (code text rewrite) to disable calling of the
|
||||
function profiler (mcount). This lets tracing be configured
|
||||
|
|
@ -130,14 +127,11 @@ of ftrace. Here is a list of some of the key files:
|
|||
be traced. If a function exists in both set_ftrace_filter
|
||||
and set_ftrace_notrace, the function will _not_ be traced.
|
||||
|
||||
available_filter_functions : When a function is encountered the first
|
||||
time by the dynamic tracer, it is recorded and
|
||||
later the call is converted into a nop. This file
|
||||
lists the functions that have been recorded
|
||||
by the dynamic tracer and these functions can
|
||||
be used to set the ftrace filter by the above
|
||||
"set_ftrace_filter" file. (See the section "dynamic ftrace"
|
||||
below for more details).
|
||||
available_filter_functions: This lists the functions that ftrace
|
||||
has processed and can trace. These are the function
|
||||
names that you can pass to "set_ftrace_filter" or
|
||||
"set_ftrace_notrace". (See the section "dynamic ftrace"
|
||||
below for more details.)
|
||||
|
||||
|
||||
The Tracers
|
||||
|
|
@ -145,7 +139,7 @@ The Tracers
|
|||
|
||||
Here is the list of current tracers that may be configured.
|
||||
|
||||
ftrace - function tracer that uses mcount to trace all functions.
|
||||
function - function tracer that uses mcount to trace all functions.
|
||||
|
||||
sched_switch - traces the context switches between tasks.
|
||||
|
||||
|
|
@ -166,8 +160,8 @@ Here is the list of current tracers that may be configured.
|
|||
the highest priority task to get scheduled after
|
||||
it has been woken up.
|
||||
|
||||
none - This is not a tracer. To remove all tracers from tracing
|
||||
simply echo "none" into current_tracer.
|
||||
nop - This is not a tracer. To remove all tracers from tracing
|
||||
simply echo "nop" into current_tracer.
|
||||
|
||||
|
||||
Examples of using the tracer
|
||||
|
|
@ -182,7 +176,7 @@ Output format:
|
|||
Here is an example of the output format of the file "trace"
|
||||
|
||||
--------
|
||||
# tracer: ftrace
|
||||
# tracer: function
|
||||
#
|
||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||
# | | | | |
|
||||
|
|
@ -192,7 +186,7 @@ Here is an example of the output format of the file "trace"
|
|||
--------
|
||||
|
||||
A header is printed with the tracer name that is represented by the trace.
|
||||
In this case the tracer is "ftrace". Then a header showing the format. Task
|
||||
In this case the tracer is "function". Then a header showing the format. Task
|
||||
name "bash", the task PID "4251", the CPU that it was running on
|
||||
"01", the timestamp in <secs>.<usecs> format, the function name that was
|
||||
traced "path_put" and the parent function that called this function
|
||||
|
|
@ -291,6 +285,9 @@ explains which is which.
|
|||
CPU#: The CPU which the process was running on.
|
||||
|
||||
irqs-off: 'd' interrupts are disabled. '.' otherwise.
|
||||
Note: If the architecture does not support a way to
|
||||
read the irq flags variable, an 'X' will always
|
||||
be printed here.
|
||||
|
||||
need-resched: 'N' task need_resched is set, '.' otherwise.
|
||||
|
||||
|
|
@ -1000,22 +997,20 @@ is the stack for the hard interrupt. This hides the fact that NEED_RESCHED
|
|||
has been set. We do not see the 'N' until we switch back to the task's
|
||||
assigned stack.
|
||||
|
||||
ftrace
|
||||
------
|
||||
function
|
||||
--------
|
||||
|
||||
ftrace is not only the name of the tracing infrastructure, but it
|
||||
is also a name of one of the tracers. The tracer is the function
|
||||
tracer. Enabling the function tracer can be done from the
|
||||
debug file system. Make sure the ftrace_enabled is set otherwise
|
||||
this tracer is a nop.
|
||||
This tracer is the function tracer. Enabling the function tracer
|
||||
can be done from the debug file system. Make sure the ftrace_enabled is
|
||||
set; otherwise this tracer is a nop.
|
||||
|
||||
# sysctl kernel.ftrace_enabled=1
|
||||
# echo ftrace > /debug/tracing/current_tracer
|
||||
# echo function > /debug/tracing/current_tracer
|
||||
# echo 1 > /debug/tracing/tracing_enabled
|
||||
# usleep 1
|
||||
# echo 0 > /debug/tracing/tracing_enabled
|
||||
# cat /debug/tracing/trace
|
||||
# tracer: ftrace
|
||||
# tracer: function
|
||||
#
|
||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||
# | | | | |
|
||||
|
|
@ -1037,10 +1032,10 @@ this tracer is a nop.
|
|||
[...]
|
||||
|
||||
|
||||
Note: ftrace uses ring buffers to store the above entries. The newest data
|
||||
may overwrite the oldest data. Sometimes using echo to stop the trace
|
||||
is not sufficient because the tracing could have overwritten the data
|
||||
that you wanted to record. For this reason, it is sometimes better to
|
||||
Note: function tracer uses ring buffers to store the above entries.
|
||||
The newest data may overwrite the oldest data. Sometimes using echo to
|
||||
stop the trace is not sufficient because the tracing could have overwritten
|
||||
the data that you wanted to record. For this reason, it is sometimes better to
|
||||
disable tracing directly from a program. This allows you to stop the
|
||||
tracing at the point that you hit the part that you are interested in.
|
||||
To disable the tracing directly from a C program, something like following
|
||||
|
|
@ -1074,18 +1069,31 @@ every kernel function, produced by the -pg switch in gcc), starts
|
|||
of pointing to a simple return. (Enabling FTRACE will include the
|
||||
-pg switch in the compiling of the kernel.)
|
||||
|
||||
When dynamic ftrace is initialized, it calls kstop_machine to make
|
||||
the machine act like a uniprocessor so that it can freely modify code
|
||||
without worrying about other processors executing that same code. At
|
||||
initialization, the mcount calls are changed to call a "record_ip"
|
||||
function. After this, the first time a kernel function is called,
|
||||
it has the calling address saved in a hash table.
|
||||
At compile time every C file object is run through the
|
||||
recordmcount.pl script (located in the scripts directory). This
|
||||
script will process the C object using objdump to find all the
|
||||
locations in the .text section that call mcount. (Note, only
|
||||
the .text section is processed, since processing other sections
|
||||
like .init.text may cause races due to those sections being freed).
|
||||
|
||||
Later on the ftraced kernel thread is awoken and will again call
|
||||
kstop_machine if new functions have been recorded. The ftraced thread
|
||||
will change all calls to mcount to "nop". Just calling mcount
|
||||
and having mcount return has shown a 10% overhead. By converting
|
||||
it to a nop, there is no measurable overhead to the system.
|
||||
A new section called "__mcount_loc" is created that holds references
|
||||
to all the mcount call sites in the .text section. This section is
|
||||
compiled back into the original object. The final linker will add
|
||||
all these references into a single table.
|
||||
|
||||
On boot up, before SMP is initialized, the dynamic ftrace code
|
||||
scans this table and updates all the locations into nops. It also
|
||||
records the locations, which are added to the available_filter_functions
|
||||
list. Modules are processed as they are loaded and before they are
|
||||
executed. When a module is unloaded, it also removes its functions from
|
||||
the ftrace function list. This is automatic in the module unload
|
||||
code, and the module author does not need to worry about it.
|
||||
|
||||
When tracing is enabled, kstop_machine is called to prevent races
|
||||
with the CPUS executing code being modified (which can cause the
|
||||
CPU to do undesireable things), and the nops are patched back
|
||||
to calls. But this time, they do not call mcount (which is just
|
||||
a function stub). They now call into the ftrace infrastructure.
|
||||
|
||||
One special side-effect to the recording of the functions being
|
||||
traced is that we can now selectively choose which functions we
|
||||
|
|
@ -1248,36 +1256,6 @@ Produces:
|
|||
|
||||
We can see that there's no more lock or preempt tracing.
|
||||
|
||||
ftraced
|
||||
-------
|
||||
|
||||
As mentioned above, when dynamic ftrace is configured in, a kernel
|
||||
thread wakes up once a second and checks to see if there are mcount
|
||||
calls that need to be converted into nops. If there are not any, then
|
||||
it simply goes back to sleep. But if there are some, it will call
|
||||
kstop_machine to convert the calls to nops.
|
||||
|
||||
There may be a case in which you do not want this added latency.
|
||||
Perhaps you are doing some audio recording and this activity might
|
||||
cause skips in the playback. There is an interface to disable
|
||||
and enable the "ftraced" kernel thread.
|
||||
|
||||
# echo 0 > /debug/tracing/ftraced_enabled
|
||||
|
||||
This will disable the calling of kstop_machine to update the
|
||||
mcount calls to nops. Remember that there is a large overhead
|
||||
to calling mcount. Without this kernel thread, that overhead will
|
||||
exist.
|
||||
|
||||
If there are recorded calls to mcount, any write to the ftraced_enabled
|
||||
file will cause the kstop_machine to run. This means that a
|
||||
user can manually perform the updates when they want to by simply
|
||||
echoing a '0' into the ftraced_enabled file.
|
||||
|
||||
The updates are also done at the beginning of enabling a tracer
|
||||
that uses ftrace function recording.
|
||||
|
||||
|
||||
trace_pipe
|
||||
----------
|
||||
|
||||
|
|
@ -1286,14 +1264,14 @@ on the tracing is different. Every read from trace_pipe is consumed.
|
|||
This means that subsequent reads will be different. The trace
|
||||
is live.
|
||||
|
||||
# echo ftrace > /debug/tracing/current_tracer
|
||||
# echo function > /debug/tracing/current_tracer
|
||||
# cat /debug/tracing/trace_pipe > /tmp/trace.out &
|
||||
[1] 4153
|
||||
# echo 1 > /debug/tracing/tracing_enabled
|
||||
# usleep 1
|
||||
# echo 0 > /debug/tracing/tracing_enabled
|
||||
# cat /debug/tracing/trace
|
||||
# tracer: ftrace
|
||||
# tracer: function
|
||||
#
|
||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||
# | | | | |
|
||||
|
|
@ -1314,7 +1292,7 @@ is live.
|
|||
|
||||
Note, reading the trace_pipe file will block until more input is added.
|
||||
By changing the tracer, trace_pipe will issue an EOF. We needed
|
||||
to set the ftrace tracer _before_ cating the trace_pipe file.
|
||||
to set the function tracer _before_ we "cat" the trace_pipe file.
|
||||
|
||||
|
||||
trace entries
|
||||
|
|
@ -1331,10 +1309,10 @@ number of entries.
|
|||
65620
|
||||
|
||||
Note, to modify this, you must have tracing completely disabled. To do that,
|
||||
echo "none" into the current_tracer. If the current_tracer is not set
|
||||
to "none", an EINVAL error will be returned.
|
||||
echo "nop" into the current_tracer. If the current_tracer is not set
|
||||
to "nop", an EINVAL error will be returned.
|
||||
|
||||
# echo none > /debug/tracing/current_tracer
|
||||
# echo nop > /debug/tracing/current_tracer
|
||||
# echo 100000 > /debug/tracing/trace_entries
|
||||
# cat /debug/tracing/trace_entries
|
||||
100045
|
||||
|
|
|
|||
|
|
@ -0,0 +1,67 @@
|
|||
Kernel driver adt7462
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Analog Devices ADT7462
|
||||
Prefix: 'adt7462'
|
||||
Addresses scanned: I2C 0x58, 0x5C
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
|
||||
Author: Darrick J. Wong
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Analog Devices ADT7462 chip family.
|
||||
|
||||
This chip is a bit of a beast. It has 8 counters for measuring fan speed. It
|
||||
can also measure 13 voltages or 4 temperatures, or various combinations of the
|
||||
two. See the chip documentation for more details about the exact set of
|
||||
configurations. This driver does not allow one to configure the chip; that is
|
||||
left to the system designer.
|
||||
|
||||
A sophisticated control system for the PWM outputs is designed into the ADT7462
|
||||
that allows fan speed to be adjusted automatically based on any of the three
|
||||
temperature sensors. Each PWM output is individually adjustable and
|
||||
programmable. Once configured, the ADT7462 will adjust the PWM outputs in
|
||||
response to the measured temperatures without further host intervention. This
|
||||
feature can also be disabled for manual control of the PWM's.
|
||||
|
||||
Each of the measured inputs (voltage, temperature, fan speed) has
|
||||
corresponding high/low limit values. The ADT7462 will signal an ALARM if
|
||||
any measured value exceeds either limit.
|
||||
|
||||
The ADT7462 samples all inputs continuously. The driver will not read
|
||||
the registers more often than once every other second. Further,
|
||||
configuration data is only read once per minute.
|
||||
|
||||
Special Features
|
||||
----------------
|
||||
|
||||
The ADT7462 have a 10-bit ADC and can therefore measure temperatures
|
||||
with 0.25 degC resolution.
|
||||
|
||||
The Analog Devices datasheet is very detailed and describes a procedure for
|
||||
determining an optimal configuration for the automatic PWM control.
|
||||
|
||||
The driver will report sensor labels when it is able to determine that
|
||||
information from the configuration registers.
|
||||
|
||||
Configuration Notes
|
||||
-------------------
|
||||
|
||||
Besides standard interfaces driver adds the following:
|
||||
|
||||
* PWM Control
|
||||
|
||||
* pwm#_auto_point1_pwm and temp#_auto_point1_temp and
|
||||
* pwm#_auto_point2_pwm and temp#_auto_point2_temp -
|
||||
|
||||
point1: Set the pwm speed at a lower temperature bound.
|
||||
point2: Set the pwm speed at a higher temperature bound.
|
||||
|
||||
The ADT7462 will scale the pwm between the lower and higher pwm speed when
|
||||
the temperature is between the two temperature boundaries. PWM values range
|
||||
from 0 (off) to 255 (full speed). Fan speed will be set to maximum when the
|
||||
temperature sensor associated with the PWM control exceeds temp#_max.
|
||||
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
Kernel driver lis3lv02d
|
||||
==================
|
||||
|
||||
Supported chips:
|
||||
|
||||
* STMicroelectronics LIS3LV02DL and LIS3LV02DQ
|
||||
|
||||
Author:
|
||||
Yan Burman <burman.yan@gmail.com>
|
||||
Eric Piel <eric.piel@tremplin-utc.net>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver provides support for the accelerometer found in various HP laptops
|
||||
sporting the feature officially called "HP Mobile Data Protection System 3D" or
|
||||
"HP 3D DriveGuard". It detect automatically laptops with this sensor. Known models
|
||||
(for now the HP 2133, nc6420, nc2510, nc8510, nc84x0, nw9440 and nx9420) will
|
||||
have their axis automatically oriented on standard way (eg: you can directly
|
||||
play neverball). The accelerometer data is readable via
|
||||
/sys/devices/platform/lis3lv02d.
|
||||
|
||||
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
|
||||
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
|
||||
calibrate - read: values (x, y, z) that are used as the base for input class device operation.
|
||||
write: forces the base to be recalibrated with the current position.
|
||||
rate - reports the sampling rate of the accelerometer device in HZ
|
||||
|
||||
This driver also provides an absolute input class device, allowing
|
||||
the laptop to act as a pinball machine-esque joystick.
|
||||
|
||||
Axes orientation
|
||||
----------------
|
||||
|
||||
For better compatibility between the various laptops. The values reported by
|
||||
the accelerometer are converted into a "standard" organisation of the axes
|
||||
(aka "can play neverball out of the box"):
|
||||
* When the laptop is horizontal the position reported is about 0 for X and Y
|
||||
and a positive value for Z
|
||||
* If the left side is elevated, X increases (becomes positive)
|
||||
* If the front side (where the touchpad is) is elevated, Y decreases (becomes negative)
|
||||
* If the laptop is put upside-down, Z becomes negative
|
||||
|
||||
If your laptop model is not recognized (cf "dmesg"), you can send an email to the
|
||||
authors to add it to the database. When reporting a new laptop, please include
|
||||
the output of "dmidecode" plus the value of /sys/devices/platform/lis3lv02d/position
|
||||
in these four cases.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
|
|||
chipsets as well: 635, and 635T. If anyone owns a board with those chips
|
||||
AND is willing to risk crashing & burning an otherwise well-behaved kernel
|
||||
in the name of progress... please contact me at <mhoffman@lightlink.com> or
|
||||
via the project's mailing list: <i2c@lm-sensors.org>. Please send bug
|
||||
via the linux-i2c mailing list: <linux-i2c@vger.kernel.org>. Please send bug
|
||||
reports and/or success stories as well.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
aliasing-test
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
Kernel driver ics932s401
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* IDT ICS932S401
|
||||
Prefix: 'ics932s401'
|
||||
Addresses scanned: I2C 0x69
|
||||
Datasheet: Publically available at the IDT website
|
||||
|
||||
Author: Darrick J. Wong
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the IDT ICS932S401 chip family.
|
||||
|
||||
This chip has 4 clock outputs--a base clock for the CPU (which is likely
|
||||
multiplied to get the real CPU clock), a system clock, a PCI clock, a USB
|
||||
clock, and a reference clock. The driver reports selected and actual
|
||||
frequency. If spread spectrum mode is enabled, the driver also reports by what
|
||||
percent the clock signal is being spread, which should be between 0 and -0.5%.
|
||||
All frequencies are reported in KHz.
|
||||
|
||||
The ICS932S401 monitors all inputs continuously. The driver will not read
|
||||
the registers more often than once every other second.
|
||||
|
||||
Special Features
|
||||
----------------
|
||||
|
||||
The clocks could be reprogrammed to increase system speed. I will not help you
|
||||
do this, as you risk damaging your system!
|
||||
|
|
@ -20,10 +20,11 @@ pressed or released a BUTTON_IRQ happens. The driver could look like:
|
|||
|
||||
static struct input_dev *button_dev;
|
||||
|
||||
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
|
||||
static irqreturn_t button_interrupt(int irq, void *dummy)
|
||||
{
|
||||
input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
|
||||
input_sync(button_dev);
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
static int __init button_init(void)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
The io_mapping functions in linux/io-mapping.h provide an abstraction for
|
||||
efficiently mapping small regions of an I/O device to the CPU. The initial
|
||||
usage is to support the large graphics aperture on 32-bit processors where
|
||||
ioremap_wc cannot be used to statically map the entire aperture to the CPU
|
||||
as it would consume too much of the kernel address space.
|
||||
|
||||
A mapping object is created during driver initialization using
|
||||
|
||||
struct io_mapping *io_mapping_create_wc(unsigned long base,
|
||||
unsigned long size)
|
||||
|
||||
'base' is the bus address of the region to be made
|
||||
mappable, while 'size' indicates how large a mapping region to
|
||||
enable. Both are in bytes.
|
||||
|
||||
This _wc variant provides a mapping which may only be used
|
||||
with the io_mapping_map_atomic_wc or io_mapping_map_wc.
|
||||
|
||||
With this mapping object, individual pages can be mapped either atomically
|
||||
or not, depending on the necessary scheduling environment. Of course, atomic
|
||||
maps are more efficient:
|
||||
|
||||
void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
|
||||
unsigned long offset)
|
||||
|
||||
'offset' is the offset within the defined mapping region.
|
||||
Accessing addresses beyond the region specified in the
|
||||
creation function yields undefined results. Using an offset
|
||||
which is not page aligned yields an undefined result. The
|
||||
return value points to a single page in CPU address space.
|
||||
|
||||
This _wc variant returns a write-combining map to the
|
||||
page and may only be used with mappings created by
|
||||
io_mapping_create_wc
|
||||
|
||||
Note that the task may not sleep while holding this page
|
||||
mapped.
|
||||
|
||||
void io_mapping_unmap_atomic(void *vaddr)
|
||||
|
||||
'vaddr' must be the the value returned by the last
|
||||
io_mapping_map_atomic_wc call. This unmaps the specified
|
||||
page and allows the task to sleep once again.
|
||||
|
||||
If you need to sleep while holding the lock, you can use the non-atomic
|
||||
variant, although they may be significantly slower.
|
||||
|
||||
void *io_mapping_map_wc(struct io_mapping *mapping,
|
||||
unsigned long offset)
|
||||
|
||||
This works like io_mapping_map_atomic_wc except it allows
|
||||
the task to sleep while holding the page mapped.
|
||||
|
||||
void io_mapping_unmap(void *vaddr)
|
||||
|
||||
This works like io_mapping_unmap_atomic, except it is used
|
||||
for pages mapped with io_mapping_map_wc.
|
||||
|
||||
At driver close time, the io_mapping object must be freed:
|
||||
|
||||
void io_mapping_free(struct io_mapping *mapping)
|
||||
|
||||
Current Implementation:
|
||||
|
||||
The initial implementation of these functions uses existing mapping
|
||||
mechanisms and so provides only an abstraction layer and no new
|
||||
functionality.
|
||||
|
||||
On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole
|
||||
range, creating a permanent kernel-visible mapping to the resource. The
|
||||
map_atomic and map functions add the requested offset to the base of the
|
||||
virtual address returned by ioremap_wc.
|
||||
|
||||
On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses
|
||||
kmap_atomic_pfn to map the specified page in an atomic fashion;
|
||||
kmap_atomic_pfn isn't really supposed to be used with device pages, but it
|
||||
provides an efficient mapping for this usage.
|
||||
|
||||
On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and
|
||||
io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which
|
||||
performs an IPI to inform all processors about the new mapping. This results
|
||||
in a significant performance penalty.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
00-INDEX
|
||||
- this file
|
||||
cdrom.txt
|
||||
- summary of CDROM ioctl calls
|
||||
hdio.txt
|
||||
- summary of HDIO_ ioctl calls
|
||||
ioctl-decoding.txt
|
||||
- how to decode the bits of an IOCTL code
|
||||
ioctl-number.txt
|
||||
- how to implement and register device/driver ioctl calls
|
||||
|
|
@ -5,7 +5,7 @@ I want to thank all who contributed to this project and especially to:
|
|||
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
|
||||
Tester, lots of bugfixes and hints.
|
||||
|
||||
Alan Cox (alan@redhat.com)
|
||||
Alan Cox (alan@lxorguk.ukuu.org.uk)
|
||||
For help getting into standard-kernel.
|
||||
|
||||
Henner Eisen (eis@baty.hanse.de)
|
||||
|
|
|
|||
|
|
@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
|
|||
fork. So if you have any comments or updates for this file, please try
|
||||
to update the original English file first.
|
||||
|
||||
Last Updated: 2008/08/21
|
||||
Last Updated: 2008/10/24
|
||||
==================================
|
||||
これは、
|
||||
linux-2.6.27/Documentation/HOWTO
|
||||
linux-2.6.28/Documentation/HOWTO
|
||||
の和訳です。
|
||||
|
||||
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
|
||||
翻訳日： 2008/8/5
|
||||
翻訳日： 2008/10/24
|
||||
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
|
||||
校正者： 松倉さん <nbh--mats at nifty dot com>
|
||||
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
|
||||
|
|
@ -110,8 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
|
|||
新しいドキュメントファイルも追加することを勧めます。
|
||||
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
|
||||
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
|
||||
をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま
|
||||
す。
|
||||
をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を
|
||||
linux-api@ver.kernel.org に送ることを勧めます。
|
||||
|
||||
以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
|
||||
す-
|
||||
|
|
@ -149,7 +149,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
|
|||
この他にパッチを作る方法についてのよくできた記述は-
|
||||
|
||||
"The Perfect Patch"
|
||||
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
|
||||
http://userweb.kernel.org/~akpm/stuff/tpp.txt
|
||||
"Linux kernel patch submission format"
|
||||
http://linux.yyz.us/patch-format.html
|
||||
|
||||
|
|
@ -664,7 +664,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
|
|||
これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
|
||||
ントの ChangeLog セクションを見てください-
|
||||
"The Perfect Patch"
|
||||
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
|
||||
http://userweb.kernel.org/~akpm/stuff/tpp.txt
|
||||
|
||||
これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
|
||||
は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ parameter is applicable:
|
|||
X86-32 X86-32, aka i386 architecture is enabled.
|
||||
X86-64 X86-64 architecture is enabled.
|
||||
More X86-64 boot options can be found in
|
||||
Documentation/x86_64/boot-options.txt .
|
||||
Documentation/x86/x86_64/boot-options.txt .
|
||||
X86 Either 32bit or 64bit x86 (same as X86-32+X86-64)
|
||||
|
||||
In addition, the following text indicates that the option:
|
||||
|
|
@ -112,10 +112,10 @@ In addition, the following text indicates that the option:
|
|||
Parameters denoted with BOOT are actually interpreted by the boot
|
||||
loader, and have no meaning to the kernel directly.
|
||||
Do not modify the syntax of boot loader parameters without extreme
|
||||
need or coordination with <Documentation/i386/boot.txt>.
|
||||
need or coordination with <Documentation/x86/i386/boot.txt>.
|
||||
|
||||
There are also arch-specific kernel-parameters not documented here.
|
||||
See for example <Documentation/x86_64/boot-options.txt>.
|
||||
See for example <Documentation/x86/x86_64/boot-options.txt>.
|
||||
|
||||
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
|
||||
a trailing = on the name of any parameter states that that parameter will
|
||||
|
|
@ -198,59 +198,42 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
that require a timer override, but don't have
|
||||
HPET
|
||||
|
||||
acpi.debug_layer= [HW,ACPI]
|
||||
acpi_backlight= [HW,ACPI]
|
||||
acpi_backlight=vendor
|
||||
acpi_backlight=video
|
||||
If set to vendor, prefer vendor specific driver
|
||||
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
|
||||
of the ACPI video.ko driver.
|
||||
|
||||
acpi_display_output= [HW,ACPI]
|
||||
acpi_display_output=vendor
|
||||
acpi_display_output=video
|
||||
See above.
|
||||
|
||||
acpi.debug_layer= [HW,ACPI,ACPI_DEBUG]
|
||||
acpi.debug_level= [HW,ACPI,ACPI_DEBUG]
|
||||
Format: <int>
|
||||
Each bit of the <int> indicates an ACPI debug layer,
|
||||
1: enable, 0: disable. It is useful for boot time
|
||||
debugging. After system has booted up, it can be set
|
||||
via /sys/module/acpi/parameters/debug_layer.
|
||||
CONFIG_ACPI_DEBUG must be enabled for this to produce any output.
|
||||
Available bits (add the numbers together) to enable debug output
|
||||
for specific parts of the ACPI subsystem:
|
||||
0x01 utilities 0x02 hardware 0x04 events 0x08 tables
|
||||
0x10 namespace 0x20 parser 0x40 dispatcher
|
||||
0x80 executer 0x100 resources 0x200 acpica debugger
|
||||
0x400 os services 0x800 acpica disassembler.
|
||||
The number can be in decimal or prefixed with 0x in hex.
|
||||
Warning: Many of these options can produce a lot of
|
||||
output and make your system unusable. Be very careful.
|
||||
CONFIG_ACPI_DEBUG must be enabled to produce any ACPI
|
||||
debug output. Bits in debug_layer correspond to a
|
||||
_COMPONENT in an ACPI source file, e.g.,
|
||||
#define _COMPONENT ACPI_PCI_COMPONENT
|
||||
Bits in debug_level correspond to a level in
|
||||
ACPI_DEBUG_PRINT statements, e.g.,
|
||||
ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
|
||||
See Documentation/acpi/debug.txt for more information
|
||||
about debug layers and levels.
|
||||
|
||||
acpi.debug_level= [HW,ACPI]
|
||||
Format: <int>
|
||||
Each bit of the <int> indicates an ACPI debug level,
|
||||
which corresponds to the level in an ACPI_DEBUG_PRINT
|
||||
statement. After system has booted up, this mask
|
||||
can be set via /sys/module/acpi/parameters/debug_level.
|
||||
Enable AML "Debug" output, i.e., stores to the Debug
|
||||
object while interpreting AML:
|
||||
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
|
||||
Enable PCI/PCI interrupt routing info messages:
|
||||
acpi.debug_layer=0x400000 acpi.debug_level=0x4
|
||||
Enable all messages related to ACPI hardware:
|
||||
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
|
||||
|
||||
CONFIG_ACPI_DEBUG must be enabled for this to produce
|
||||
any output. The number can be in decimal or prefixed
|
||||
with 0x in hex. Some of these options produce so much
|
||||
output that the system is unusable.
|
||||
|
||||
The following global components are defined by the
|
||||
ACPI CA:
|
||||
0x01 error
|
||||
0x02 warn
|
||||
0x04 init
|
||||
0x08 debug object
|
||||
0x10 info
|
||||
0x20 init names
|
||||
0x40 parse
|
||||
0x80 load
|
||||
0x100 dispatch
|
||||
0x200 execute
|
||||
0x400 names
|
||||
0x800 operation region
|
||||
0x1000 bfield
|
||||
0x2000 tables
|
||||
0x4000 values
|
||||
0x8000 objects
|
||||
0x10000 resources
|
||||
0x20000 user requests
|
||||
0x40000 package
|
||||
The number can be in decimal or prefixed with 0x in hex.
|
||||
Warning: Many of these options can produce a lot of
|
||||
output and make your system unusable. Be very careful.
|
||||
Some values produce so much output that the system is
|
||||
unusable. The "log_buf_len" parameter may be useful
|
||||
if you need to capture more output.
|
||||
|
||||
acpi.power_nocheck= [HW,ACPI]
|
||||
Format: 1/0 enable/disable the check of power state.
|
||||
|
|
@ -311,7 +294,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Possible values are:
|
||||
isolate - enable device isolation (each device, as far
|
||||
as possible, will get its own protection
|
||||
domain)
|
||||
domain) [default]
|
||||
share - put every device behind one IOMMU into the
|
||||
same protection domain
|
||||
fullflush - enable flushing of IO/TLB entries when
|
||||
they are unmapped. Otherwise they are
|
||||
flushed before they will be reused, which
|
||||
|
|
@ -646,7 +631,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
digiepca= [HW,SERIAL]
|
||||
See drivers/char/README.epca and
|
||||
Documentation/digiepca.txt.
|
||||
Documentation/serial/digiepca.txt.
|
||||
|
||||
disable_mtrr_cleanup [X86]
|
||||
enable_mtrr_cleanup [X86]
|
||||
|
|
@ -757,7 +742,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See header of drivers/scsi/fdomain.c.
|
||||
|
||||
floppy= [HW]
|
||||
See Documentation/floppy.txt.
|
||||
See Documentation/blockdev/floppy.txt.
|
||||
|
||||
force_pal_cache_flush
|
||||
[IA-64] Avoid check_sal_cache_flush which may hang on
|
||||
|
|
@ -995,13 +980,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Format:
|
||||
<cpu number>,...,<cpu number>
|
||||
or
|
||||
<cpu number>-<cpu number> (must be a positive range in ascending order)
|
||||
<cpu number>-<cpu number>
|
||||
(must be a positive range in ascending order)
|
||||
or a mixture
|
||||
<cpu number>,...,<cpu number>-<cpu number>
|
||||
|
||||
This option can be used to specify one or more CPUs
|
||||
to isolate from the general SMP balancing and scheduling
|
||||
algorithms. The only way to move a process onto or off
|
||||
an "isolated" CPU is via the CPU affinity syscalls.
|
||||
algorithms. You can move a process onto or off an
|
||||
"isolated" CPU via the CPU affinity syscalls or cpuset.
|
||||
<cpu number> begins at 0 and the maximum value is
|
||||
"number of CPUs in system - 1".
|
||||
|
||||
|
|
@ -1116,7 +1103,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
the same attribute, the last one is used.
|
||||
|
||||
load_ramdisk= [RAM] List of ramdisks to load from floppy
|
||||
See Documentation/ramdisk.txt.
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
lockd.nlm_grace_period=P [NFS] Assign grace period.
|
||||
Format: <integer>
|
||||
|
|
@ -1208,8 +1195,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
it is equivalent to "nosmp", which also disables
|
||||
the IO APIC.
|
||||
|
||||
max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or
|
||||
equal to this physical address is ignored.
|
||||
max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater than
|
||||
or equal to this physical address is ignored.
|
||||
|
||||
max_luns= [SCSI] Maximum number of LUNs to probe.
|
||||
Should be between 1 and 2^32-1.
|
||||
|
|
@ -1222,7 +1209,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
mce [X86-32] Machine Check Exception
|
||||
|
||||
mce=option [X86-64] See Documentation/x86_64/boot-options.txt
|
||||
mce=option [X86-64] See Documentation/x86/x86_64/boot-options.txt
|
||||
|
||||
md= [HW] RAID subsystems devices and level
|
||||
See Documentation/md.txt.
|
||||
|
|
@ -1309,6 +1296,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
mga= [HW,DRM]
|
||||
|
||||
min_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory below this
|
||||
physical address is ignored.
|
||||
|
||||
mminit_loglevel=
|
||||
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
|
||||
parameter allows control of the logging verbosity for
|
||||
|
|
@ -1470,8 +1460,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Valid arguments: on, off
|
||||
Default: on
|
||||
|
||||
noirqbalance [X86-32,SMP,KNL] Disable kernel irq balancing
|
||||
|
||||
noirqdebug [X86-32] Disables the code which attempts to detect and
|
||||
disable unhandled interrupt sources.
|
||||
|
||||
|
|
@ -1613,7 +1601,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
pcd. [PARIDE]
|
||||
See header of drivers/block/paride/pcd.c.
|
||||
See also Documentation/paride.txt.
|
||||
See also Documentation/blockdev/paride.txt.
|
||||
|
||||
pci=option[,option...] [PCI] various PCI subsystem options:
|
||||
off [X86] don't probe for the PCI bus
|
||||
|
|
@ -1714,7 +1702,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
pcmv= [HW,PCMCIA] BadgePAD 4
|
||||
|
||||
pd. [PARIDE]
|
||||
See Documentation/paride.txt.
|
||||
See Documentation/blockdev/paride.txt.
|
||||
|
||||
pdcchassis= [PARISC,HW] Disable/Enable PDC Chassis Status codes at
|
||||
boot time.
|
||||
|
|
@ -1722,13 +1710,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See arch/parisc/kernel/pdc_chassis.c
|
||||
|
||||
pf. [PARIDE]
|
||||
See Documentation/paride.txt.
|
||||
See Documentation/blockdev/paride.txt.
|
||||
|
||||
pg. [PARIDE]
|
||||
See Documentation/paride.txt.
|
||||
See Documentation/blockdev/paride.txt.
|
||||
|
||||
pirq= [SMP,APIC] Manual mp-table setup
|
||||
See Documentation/i386/IO-APIC.txt.
|
||||
See Documentation/x86/i386/IO-APIC.txt.
|
||||
|
||||
plip= [PPT,NET] Parallel port network link
|
||||
Format: { parport<nr> | timid | 0 }
|
||||
|
|
@ -1795,7 +1783,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
|
||||
before loading.
|
||||
See Documentation/ramdisk.txt.
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
psmouse.proto= [HW,MOUSE] Highest PS2 mouse protocol extension to
|
||||
probe for; one of (bare|imps|exps|lifebook|any).
|
||||
|
|
@ -1815,7 +1803,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
<io>,<mss_io>,<mss_irq>,<mss_dma>,<mpu_io>,<mpu_irq>
|
||||
|
||||
pt. [PARIDE]
|
||||
See Documentation/paride.txt.
|
||||
See Documentation/blockdev/paride.txt.
|
||||
|
||||
pty.legacy_count=
|
||||
[KNL] Number of legacy pty's. Overwrites compiled-in
|
||||
|
|
@ -1829,10 +1817,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See Documentation/md.txt.
|
||||
|
||||
ramdisk_blocksize= [RAM]
|
||||
See Documentation/ramdisk.txt.
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
|
||||
See Documentation/ramdisk.txt.
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
rcupdate.blimit= [KNL,BOOT]
|
||||
Set maximum number of finished RCU callbacks to process
|
||||
|
|
@ -2164,7 +2152,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See Documentation/sonypi.txt
|
||||
|
||||
specialix= [HW,SERIAL] Specialix multi-serial port adapter
|
||||
See Documentation/specialix.txt.
|
||||
See Documentation/serial/specialix.txt.
|
||||
|
||||
spia_io_base= [HW,MTD]
|
||||
spia_fio_base=
|
||||
|
|
@ -2343,7 +2331,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See Documentation/fb/modedb.txt.
|
||||
|
||||
vga= [BOOT,X86-32] Select a particular video mode
|
||||
See Documentation/i386/boot.txt and
|
||||
See Documentation/x86/i386/boot.txt and
|
||||
Documentation/svga.txt.
|
||||
Use vga=ask for menu.
|
||||
This is actually a boot loader parameter; the value is
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# This creates the demonstration utility "lguest" which runs a Linux guest.
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include
|
||||
LDLIBS:=-lz
|
||||
|
||||
all: lguest
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@
|
|||
#include "linux/virtio_console.h"
|
||||
#include "linux/virtio_rng.h"
|
||||
#include "linux/virtio_ring.h"
|
||||
#include "asm-x86/bootparam.h"
|
||||
#include "asm/bootparam.h"
|
||||
/*L:110 We can ignore the 39 include files we need for this program, but I do
|
||||
* want to draw attention to the use of kernel-style types.
|
||||
*
|
||||
|
|
@ -402,7 +402,7 @@ static unsigned long load_bzimage(int fd)
|
|||
void *p = from_guest_phys(0x100000);
|
||||
|
||||
/* Go back to the start of the file and read the header. It should be
|
||||
* a Linux boot header (see Documentation/i386/boot.txt) */
|
||||
* a Linux boot header (see Documentation/x86/i386/boot.txt) */
|
||||
lseek(fd, 0, SEEK_SET);
|
||||
read(fd, &boot, sizeof(boot));
|
||||
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ static void do_test_timer(unsigned long data)
|
|||
int cpu;
|
||||
|
||||
/* Increment the counters */
|
||||
on_each_cpu(test_each, NULL, 0, 1);
|
||||
on_each_cpu(test_each, NULL, 1);
|
||||
/* Read all the counters */
|
||||
printk("Counters read from CPU %d\n", smp_processor_id());
|
||||
for_each_online_cpu(cpu) {
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
ifenslave
|
||||
|
|
@ -60,6 +60,6 @@ Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
|
|||
Contributors:
|
||||
|
||||
Marcelo Tosatti <marcelo@conectiva.com.br>
|
||||
Alan Cox <alan@redhat.com>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Jeff Garzik <jgarzik@pobox.com>
|
||||
Vojtech Pavlik <vojtech@suse.cz>
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ Letting the PHY Abstraction Layer do Everything
|
|||
static void adjust_link(struct net_device *dev);
|
||||
|
||||
Next, you need to know the device name of the PHY connected to this device.
|
||||
The name will look something like, "phy0:0", where the first number is the
|
||||
The name will look something like, "0:00", where the first number is the
|
||||
bus id, and the second is the PHY's address on that bus. Typically,
|
||||
the bus is responsible for making its ID unique.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
crc32hash
|
||||
|
|
@ -41,25 +41,14 @@ Table of Contents
|
|||
VI - System-on-a-chip devices and nodes
|
||||
1) Defining child nodes of an SOC
|
||||
2) Representing devices without a current OF specification
|
||||
a) MDIO IO device
|
||||
b) Gianfar-compatible ethernet nodes
|
||||
c) PHY nodes
|
||||
d) Interrupt controllers
|
||||
e) I2C
|
||||
f) Freescale SOC USB controllers
|
||||
g) Freescale SOC SEC Security Engines
|
||||
h) Board Control and Status (BCSR)
|
||||
i) Freescale QUICC Engine module (QE)
|
||||
j) CFI or JEDEC memory-mapped NOR flash
|
||||
k) Global Utilities Block
|
||||
l) Freescale Communications Processor Module
|
||||
m) Chipselect/Local Bus
|
||||
n) 4xx/Axon EMAC ethernet nodes
|
||||
o) Xilinx IP cores
|
||||
p) Freescale Synchronous Serial Interface
|
||||
q) USB EHCI controllers
|
||||
r) MDIO on GPIOs
|
||||
s) SPI busses
|
||||
a) PHY nodes
|
||||
b) Interrupt controllers
|
||||
c) CFI or JEDEC memory-mapped NOR flash
|
||||
d) 4xx/Axon EMAC ethernet nodes
|
||||
e) Xilinx IP cores
|
||||
f) USB EHCI controllers
|
||||
g) MDIO on GPIOs
|
||||
h) SPI busses
|
||||
|
||||
VII - Marvell Discovery mv64[345]6x System Controller chips
|
||||
1) The /system-controller node
|
||||
|
|
@ -1830,41 +1819,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
big-endian;
|
||||
};
|
||||
|
||||
r) Freescale Display Interface Unit
|
||||
|
||||
The Freescale DIU is a LCD controller, with proper hardware, it can also
|
||||
drive DVI monitors.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "fsl-diu".
|
||||
- reg : should contain at least address and length of the DIU register
|
||||
set.
|
||||
- Interrupts : one DIU interrupt should be describe here.
|
||||
|
||||
Example (MPC8610HPCD)
|
||||
display@2c000 {
|
||||
compatible = "fsl,diu";
|
||||
reg = <0x2c000 100>;
|
||||
interrupts = <72 2>;
|
||||
interrupt-parent = <&mpic>;
|
||||
};
|
||||
|
||||
s) Freescale on board FPGA
|
||||
|
||||
This is the memory-mapped registers for on board FPGA.
|
||||
|
||||
Required properities:
|
||||
- compatible : should be "fsl,fpga-pixis".
|
||||
- reg : should contain the address and the lenght of the FPPGA register
|
||||
set.
|
||||
|
||||
Example (MPC8610HPCD)
|
||||
board-control@e8000000 {
|
||||
compatible = "fsl,fpga-pixis";
|
||||
reg = <0xe8000000 32>;
|
||||
};
|
||||
|
||||
r) MDIO on GPIOs
|
||||
g) MDIO on GPIOs
|
||||
|
||||
Currently defined compatibles:
|
||||
- virtual,gpio-mdio
|
||||
|
|
@ -1884,7 +1839,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
&qe_pio_c 6>;
|
||||
};
|
||||
|
||||
s) SPI (Serial Peripheral Interface) busses
|
||||
h) SPI (Serial Peripheral Interface) busses
|
||||
|
||||
SPI busses can be described with a node for the SPI master device
|
||||
and a set of child nodes for each SPI slave on the bus. For this
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
If variable is of Type, use printk format specifier:
|
||||
---------------------------------------------------------
|
||||
int %d or %x
|
||||
unsigned int %u or %x
|
||||
long %ld or %lx
|
||||
unsigned long %lu or %lx
|
||||
long long %lld or %llx
|
||||
unsigned long long %llu or %llx
|
||||
size_t %zu or %zx
|
||||
ssize_t %zd or %zx
|
||||
|
||||
Raw pointer value SHOULD be printed with %p.
|
||||
|
||||
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
|
||||
|
||||
printk("%llu", (unsigned long long)u64_var);
|
||||
|
||||
s64 SHOULD be printed with %lld/%llx, (long long):
|
||||
|
||||
printk("%lld", (long long)s64_var);
|
||||
|
||||
If <type> is dependent on a config option for its size (e.g., sector_t,
|
||||
blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
|
||||
for its size (e.g., tcflag_t), use a format specifier of its largest
|
||||
possible type and explicitly cast to it. Example:
|
||||
|
||||
printk("test: sector number/total blocks: %llu/%llu\n",
|
||||
(unsigned long long)sector, (unsigned long long)blockcount);
|
||||
|
||||
Reminder: sizeof() result is of type size_t.
|
||||
|
||||
Thank you for your cooperation and attention.
|
||||
|
||||
|
||||
By Randy Dunlap <rdunlap@xenotime.net>
|
||||
|
|
@ -4,8 +4,6 @@ sched-arch.txt
|
|||
- CPU Scheduler implementation hints for architecture specific code.
|
||||
sched-coding.txt
|
||||
- reference for various scheduler-related methods in the O(1) scheduler.
|
||||
sched-design.txt
|
||||
- goals, design and implementation of the Linux O(1) scheduler.
|
||||
sched-design-CFS.txt
|
||||
- goals, design and implementation of the Complete Fair Scheduler.
|
||||
sched-domains.txt
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ other HZ detail. Thus the CFS scheduler has no notion of "timeslices" in the
|
|||
way the previous scheduler had, and has no heuristics whatsoever. There is
|
||||
only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):
|
||||
|
||||
/proc/sys/kernel/sched_granularity_ns
|
||||
/proc/sys/kernel/sched_min_granularity_ns
|
||||
|
||||
which can be used to tune the scheduler from "desktop" (i.e., low latencies) to
|
||||
"server" (i.e., good batching) workloads. It defaults to a setting suitable
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ Supported Cards/Chipsets
|
|||
|
||||
People
|
||||
-------------------------
|
||||
Alan Cox <alan@redhat.com>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Christoph Hellwig <hch@infradead.org> (updates for new-style PCI probing and SCSI host registration,
|
||||
small cleanups/fixes)
|
||||
Matt Domsch <matt_domsch@dell.com> (revision ioctl, adapter messages)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
00-INDEX
|
||||
- this file.
|
||||
README.cycladesZ
|
||||
- info on Cyclades-Z firmware loading.
|
||||
computone.txt
|
||||
- info on Computone Intelliport II/Plus Multiport Serial Driver.
|
||||
digiepca.txt
|
||||
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
|
||||
hayes-esp.txt
|
||||
- info on using the Hayes ESP serial driver.
|
||||
moxa-smartio
|
||||
- file with info on installing/using Moxa multiport serial driver.
|
||||
riscom8.txt
|
||||
- notes on using the RISCom/8 multi-port serial driver.
|
||||
rocket.txt
|
||||
- info on the Comtrol RocketPort multiport serial driver.
|
||||
specialix.txt
|
||||
- info on hardware/driver for specialix IO8+ multiport serial card.
|
||||
stallion.txt
|
||||
- info on using the Stallion multiport serial driver.
|
||||
sx.txt
|
||||
- info on the Specialix SX/SI multiport serial driver.
|
||||
tty.txt
|
||||
- guide to the locking policies of the tty layer.
|
||||
|
|
@ -247,7 +247,7 @@ shar archive to make it easier to extract the script from the documentation.
|
|||
To create the ip2mkdev shell script change to a convenient directory (/tmp
|
||||
works just fine) and run the following command:
|
||||
|
||||
unshar Documentation/computone.txt
|
||||
unshar Documentation/serial/computone.txt
|
||||
(This file)
|
||||
|
||||
You should now have a file ip2mkdev in your current working directory with
|
||||
|
|
@ -47,9 +47,7 @@ Next, for companion chips:
|
|||
`-- sh
|
||||
`-- cchips
|
||||
`-- hd6446x
|
||||
|-- hd64461
|
||||
| `-- cchip-specific files
|
||||
`-- hd64465
|
||||
`-- hd64461
|
||||
`-- cchip-specific files
|
||||
|
||||
... and so on. Headers for the companion chips are treated the same way as
|
||||
|
|
|
|||
|
|
@ -1072,10 +1072,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
ref Reference board
|
||||
dell-m4-1 Dell desktops
|
||||
dell-m4-2 Dell desktops
|
||||
dell-m4-3 Dell desktops
|
||||
|
||||
STAC92HD73*
|
||||
ref Reference board
|
||||
dell-m6 Dell desktops
|
||||
dell-m6-amic Dell desktops/laptops with analog mics
|
||||
dell-m6-dmic Dell desktops/laptops with digital mics
|
||||
dell-m6 Dell desktops/laptops with both type of mics
|
||||
|
||||
STAC9872
|
||||
vaio Setup for VAIO FE550G/SZ110
|
||||
|
|
|
|||
|
|
@ -0,0 +1,2 @@
|
|||
spidev_fdx
|
||||
spidev_test
|
||||
|
|
@ -215,7 +215,7 @@ So for example arch/.../mach-*/board-*.c files might have code like:
|
|||
/* if your mach-* infrastructure doesn't support kernels that can
|
||||
* run on multiple boards, pdata wouldn't benefit from "__init".
|
||||
*/
|
||||
static struct mysoc_spi_data __init pdata = { ... };
|
||||
static struct mysoc_spi_data __initdata pdata = { ... };
|
||||
|
||||
static __init board_init(void)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
|
|||
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
|
||||
security issue, or some "oh, that's not good" issue. In short, something
|
||||
critical.
|
||||
- New device IDs and quirks are also accepted.
|
||||
- No "theoretical race condition" issues, unless an explanation of how the
|
||||
race can be exploited is also provided.
|
||||
- It cannot contain any "trivial" fixes in it (spelling changes,
|
||||
|
|
|
|||
|
|
@ -363,11 +363,21 @@ tainted:
|
|||
Non-zero if the kernel has been tainted. Numeric values, which
|
||||
can be ORed together:
|
||||
|
||||
1 - A module with a non-GPL license has been loaded, this
|
||||
includes modules with no license.
|
||||
Set by modutils >= 2.4.9 and module-init-tools.
|
||||
2 - A module was force loaded by insmod -f.
|
||||
Set by modutils >= 2.4.9 and module-init-tools.
|
||||
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
|
||||
64 - A module from drivers/staging was loaded.
|
||||
1 - A module with a non-GPL license has been loaded, this
|
||||
includes modules with no license.
|
||||
Set by modutils >= 2.4.9 and module-init-tools.
|
||||
2 - A module was force loaded by insmod -f.
|
||||
Set by modutils >= 2.4.9 and module-init-tools.
|
||||
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
|
||||
8 - A module was forcibly unloaded from the system by rmmod -f.
|
||||
16 - A hardware machine check error occurred on the system.
|
||||
32 - A bad page was discovered on the system.
|
||||
64 - The user has asked that the system be marked "tainted". This
|
||||
could be because they are running software that directly modifies
|
||||
the hardware, or for other reasons.
|
||||
128 - The system has died.
|
||||
256 - The ACPI DSDT has been overridden with one supplied by the user
|
||||
instead of using the one provided by the hardware.
|
||||
512 - A kernel warning has occurred.
|
||||
1024 - A module from drivers/staging was loaded.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ $ echo mmiotrace > /debug/tracing/current_tracer
|
|||
$ cat /debug/tracing/trace_pipe > mydump.txt &
|
||||
Start X or whatever.
|
||||
$ echo "X is up" > /debug/tracing/trace_marker
|
||||
$ echo none > /debug/tracing/current_tracer
|
||||
$ echo nop > /debug/tracing/current_tracer
|
||||
Check for lost events.
|
||||
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ which action. It is recommended to place descriptive markers about what you
|
|||
do.
|
||||
|
||||
Shut down mmiotrace (requires root privileges):
|
||||
$ echo none > /debug/tracing/current_tracer
|
||||
$ echo nop > /debug/tracing/current_tracer
|
||||
The 'cat' process exits. If it does not, kill it by issuing 'fg' command and
|
||||
pressing ctrl+c.
|
||||
|
||||
|
|
@ -81,7 +81,9 @@ are:
|
|||
$ cat /debug/tracing/trace_entries
|
||||
gives you a number. Approximately double this number and write it back, for
|
||||
instance:
|
||||
$ echo 0 > /debug/tracing/tracing_enabled
|
||||
$ echo 128000 > /debug/tracing/trace_entries
|
||||
$ echo 1 > /debug/tracing/tracing_enabled
|
||||
Then start again from the top.
|
||||
|
||||
If you are doing a trace for a driver project, e.g. Nouveau, you should also
|
||||
|
|
|
|||
|
|
@ -114,11 +114,11 @@ modules.
|
|||
Then you must load the gadget serial driver. To load it as an
|
||||
ACM device (recommended for interoperability), do this:
|
||||
|
||||
modprobe g_serial use_acm=1
|
||||
modprobe g_serial
|
||||
|
||||
To load it as a vendor specific bulk in/out device, do this:
|
||||
|
||||
modprobe g_serial
|
||||
modprobe g_serial use_acm=0
|
||||
|
||||
This will also automatically load the underlying gadget peripheral
|
||||
controller driver. This must be done each time you reboot the gadget
|
||||
|
|
|
|||
|
|
@ -49,8 +49,10 @@ it and 002/048 sometime later.
|
|||
|
||||
These files can be read as binary data. The binary data consists
|
||||
of first the device descriptor, then the descriptors for each
|
||||
configuration of the device. That information is also shown in
|
||||
text form by the /proc/bus/usb/devices file, described later.
|
||||
configuration of the device. Multi-byte fields in the device and
|
||||
configuration descriptors, but not other descriptors, are converted
|
||||
to host endianness by the kernel. This information is also shown
|
||||
in text form by the /proc/bus/usb/devices file, described later.
|
||||
|
||||
These files may also be used to write user-level drivers for the USB
|
||||
devices. You would open the /proc/bus/usb/BBB/DDD file read/write,
|
||||
|
|
|
|||
|
|
@ -34,11 +34,12 @@ if usbmon is built into the kernel.
|
|||
Verify that bus sockets are present.
|
||||
|
||||
# ls /sys/kernel/debug/usbmon
|
||||
0s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
|
||||
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
|
||||
#
|
||||
|
||||
Now you can choose to either use the sockets numbered '0' (to capture packets on
|
||||
all buses), and skip to step #3, or find the bus used by your device with step #2.
|
||||
Now you can choose to either use the socket '0u' (to capture packets on all
|
||||
buses), and skip to step #3, or find the bus used by your device with step #2.
|
||||
This allows to filter away annoying devices that talk continuously.
|
||||
|
||||
2. Find which bus connects to the desired device
|
||||
|
||||
|
|
@ -99,8 +100,9 @@ on the event type, but there is a set of words, common for all types.
|
|||
|
||||
Here is the list of words, from left to right:
|
||||
|
||||
- URB Tag. This is used to identify URBs is normally a kernel mode address
|
||||
of the URB structure in hexadecimal.
|
||||
- URB Tag. This is used to identify URBs, and is normally an in-kernel address
|
||||
of the URB structure in hexadecimal, but can be a sequence number or any
|
||||
other unique string, within reason.
|
||||
|
||||
- Timestamp in microseconds, a decimal number. The timestamp's resolution
|
||||
depends on available clock, and so it can be much worse than a microsecond
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
v4lgrab
|
||||
|
|
@ -27,8 +27,8 @@ audio
|
|||
sound card) should be possible, but there is no code yet ...
|
||||
|
||||
vbi
|
||||
- some code present. Doesn't crash any more, but also doesn't
|
||||
work yet ...
|
||||
- Code present. Works for NTSC closed caption. PAL and other
|
||||
TV norms may or may not work.
|
||||
|
||||
|
||||
how to add support for new cards
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Contributors to bttv:
|
|||
Michael Chu <mmchu@pobox.com>
|
||||
AverMedia fix and more flexible card recognition
|
||||
|
||||
Alan Cox <alan@redhat.com>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Video4Linux interface and 2.1.x kernel adaptation
|
||||
|
||||
Chris Kleitsch
|
||||
|
|
|
|||
|
|
@ -0,0 +1,118 @@
|
|||
Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers
|
||||
|
||||
Copyright (c) 2008 Tobias Lorenz <tobias.lorenz@gmx.net>
|
||||
|
||||
|
||||
Information from Silicon Labs
|
||||
=============================
|
||||
Silicon Laboratories is the manufacturer of the radio ICs, that nowadays are the
|
||||
most often used radio receivers in cell phones. Usually they are connected with
|
||||
I2C. But SiLabs also provides a reference design, which integrates this IC,
|
||||
together with a small microcontroller C8051F321, to form a USB radio.
|
||||
Part of this reference design is also a radio application in binary and source
|
||||
code. The software also contains an automatic firmware upgrade to the most
|
||||
current version. Information on these can be downloaded here:
|
||||
http://www.silabs.com/usbradio
|
||||
|
||||
|
||||
Supported ICs
|
||||
=============
|
||||
The following ICs have a very similar register set, so that they are or will be
|
||||
supported somewhen by the driver:
|
||||
- Si4700: FM radio receiver
|
||||
- Si4701: FM radio receiver, RDS Support
|
||||
- Si4702: FM radio receiver
|
||||
- Si4703: FM radio receiver, RDS Support
|
||||
- Si4704: FM radio receiver, no external antenna required
|
||||
- Si4705: FM radio receiver, no external antenna required, RDS support, Dig I/O
|
||||
- Si4706: Enhanced FM RDS/TMC radio receiver, no external antenna required, RDS
|
||||
Support
|
||||
- Si4707: Dedicated weather band radio receiver with SAME decoder, RDS Support
|
||||
- Si4708: Smallest FM receivers
|
||||
- Si4709: Smallest FM receivers, RDS Support
|
||||
More information on these can be downloaded here:
|
||||
http://www.silabs.com/products/mcu/Pages/USBFMRadioRD.aspx
|
||||
|
||||
|
||||
Supported USB devices
|
||||
=====================
|
||||
Currently the following USB radios (vendor:product) with the Silicon Labs si470x
|
||||
chips are known to work:
|
||||
- 10c4:818a: Silicon Labs USB FM Radio Reference Design
|
||||
- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF)
|
||||
- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700)
|
||||
|
||||
|
||||
Software
|
||||
========
|
||||
Testing is usually done with most application under Debian/testing:
|
||||
- fmtools - Utility for managing FM tuner cards
|
||||
- gnomeradio - FM-radio tuner for the GNOME desktop
|
||||
- gradio - GTK FM radio tuner
|
||||
- kradio - Comfortable Radio Application for KDE
|
||||
- radio - ncurses-based radio application
|
||||
|
||||
There is also a library libv4l, which can be used. It's going to have a function
|
||||
for frequency seeking, either by using hardware functionality as in radio-si470x
|
||||
or by implementing a function as we currently have in every of the mentioned
|
||||
programs. Somewhen the radio programs should make use of libv4l.
|
||||
|
||||
For processing RDS information, there is a project ongoing at:
|
||||
http://rdsd.berlios.de/
|
||||
|
||||
There is currently no project for making TMC sentences human readable.
|
||||
|
||||
|
||||
Audio Listing
|
||||
=============
|
||||
USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to
|
||||
also select SND_USB_AUDIO, as this is required to get sound from the radio. For
|
||||
listing you have to redirect the sound, for example using one of the following
|
||||
commands.
|
||||
|
||||
If you just want to test audio (very poor quality):
|
||||
cat /dev/dsp1 > /dev/dsp
|
||||
|
||||
If you use OSS try:
|
||||
sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
|
||||
|
||||
If you use arts try:
|
||||
arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
|
||||
|
||||
|
||||
Module Parameters
|
||||
=================
|
||||
After loading the module, you still have access to some of them in the sysfs
|
||||
mount under /sys/module/radio_si470x/parameters. The contents of read-only files
|
||||
(0444) are not updated, even if space, band and de are changed using private
|
||||
video controls. The others are runtime changeable.
|
||||
|
||||
|
||||
Errors
|
||||
======
|
||||
Increase tune_timeout, if you often get -EIO errors.
|
||||
|
||||
When timed out or band limit is reached, hw_freq_seek returns -EAGAIN.
|
||||
|
||||
If you get any errors from snd_usb_audio, please report them to the ALSA people.
|
||||
|
||||
|
||||
Open Issues
|
||||
===========
|
||||
V4L minor device allocation and parameter setting is not perfect. A solution is
|
||||
currently under discussion.
|
||||
|
||||
There is an USB interface for downloading/uploading new firmware images. Support
|
||||
for it can be implemented using the request_firmware interface.
|
||||
|
||||
There is a RDS interrupt mode. The driver is already using the same interface
|
||||
for polling RDS information, but is currently not using the interrupt mode.
|
||||
|
||||
There is a LED interface, which can be used to override the LED control
|
||||
programmed in the firmware. This can be made available using the LED support
|
||||
functions in the kernel.
|
||||
|
||||
|
||||
Other useful information and links
|
||||
==================================
|
||||
http://www.silabs.com/usbradio
|
||||
|
|
@ -0,0 +1 @@
|
|||
slabinfo
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
Kernel driver for omap HDQ/1-wire module.
|
||||
========================================
|
||||
|
||||
Supported chips:
|
||||
================
|
||||
HDQ/1-wire controller on the TI OMAP 2430/3430 platforms.
|
||||
|
||||
A useful link about HDQ basics:
|
||||
===============================
|
||||
http://focus.ti.com/lit/an/slua408/slua408.pdf
|
||||
|
||||
Description:
|
||||
============
|
||||
The HDQ/1-Wire module of TI OMAP2430/3430 platforms implement the hardware
|
||||
protocol of the master functions of the Benchmark HDQ and the Dallas
|
||||
Semiconductor 1-Wire protocols. These protocols use a single wire for
|
||||
communication between the master (HDQ/1-Wire controller) and the slave
|
||||
(HDQ/1-Wire external compliant device).
|
||||
|
||||
A typical application of the HDQ/1-Wire module is the communication with battery
|
||||
monitor (gas gauge) integrated circuits.
|
||||
|
||||
The controller supports operation in both HDQ and 1-wire mode. The essential
|
||||
difference between the HDQ and 1-wire mode is how the slave device responds to
|
||||
initialization pulse.In HDQ mode, the firmware does not require the host to
|
||||
create an initialization pulse to the slave.However, the slave can be reset by
|
||||
using an initialization pulse (also referred to as a break pulse).The slave
|
||||
does not respond with a presence pulse as it does in the 1-Wire protocol.
|
||||
|
||||
Remarks:
|
||||
========
|
||||
The driver (drivers/w1/masters/omap_hdq.c) supports the HDQ mode of the
|
||||
controller. In this mode, as we can not read the ID which obeys the W1
|
||||
spec(family:id:crc), a module parameter can be passed to the driver which will
|
||||
be used to calculate the CRC and pass back an appropriate slave ID to the W1
|
||||
core.
|
||||
|
||||
By default the master driver and the BQ slave i/f
|
||||
driver(drivers/w1/slaves/w1_bq27000.c) sets the ID to 1.
|
||||
Please note to load both the modules with a different ID if required, but note
|
||||
that the ID used should be same for both master and slave driver loading.
|
||||
|
||||
e.g:
|
||||
insmod omap_hdq.ko W1_ID=2
|
||||
inamod w1_bq27000.ko F_ID=2
|
||||
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
watchdog-simple
|
||||
watchdog-test
|
||||
|
|
@ -35,7 +35,7 @@ APICs
|
|||
|
||||
nolapic Don't use the local APIC (alias for i386 compatibility)
|
||||
|
||||
pirq=... See Documentation/i386/IO-APIC.txt
|
||||
pirq=... See Documentation/x86/i386/IO-APIC.txt
|
||||
|
||||
noapictimer Don't set up the APIC timer
|
||||
|
||||
|
|
@ -139,7 +139,7 @@ Non Executable Mappings
|
|||
SMP
|
||||
|
||||
additional_cpus=NUM Allow NUM more CPUs for hotplug
|
||||
(defaults are specified by the BIOS, see Documentation/x86_64/cpu-hotplug-spec)
|
||||
(defaults are specified by the BIOS, see Documentation/x86/x86_64/cpu-hotplug-spec)
|
||||
|
||||
NUMA
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ amount of system memory that are available to a certain class of tasks.
|
|||
For more information on the features of cpusets, see Documentation/cpusets.txt.
|
||||
There are a number of different configurations you can use for your needs. For
|
||||
more information on the numa=fake command line option and its various ways of
|
||||
configuring fake nodes, see Documentation/x86_64/boot-options.txt.
|
||||
configuring fake nodes, see Documentation/x86/x86_64/boot-options.txt.
|
||||
|
||||
For the purposes of this introduction, we'll assume a very primitive NUMA
|
||||
emulation setup of "numa=fake=4*512,". This will split our system memory into
|
||||
|
|
|
|||
116
MAINTAINERS
116
MAINTAINERS
|
|
@ -347,7 +347,7 @@ S: Maintained
|
|||
ALI1563 I2C DRIVER
|
||||
P: Rudolf Marek
|
||||
M: r.marek@assembler.cz
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
ALPHA PORT
|
||||
|
|
@ -610,6 +610,11 @@ P: Philipp Zabel
|
|||
M: philipp.zabel@gmail.com
|
||||
S: Maintained
|
||||
|
||||
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
|
||||
P: Michael Petchkovsky
|
||||
M: mkpetch@internode.on.net
|
||||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dmitry Baryshkov
|
||||
M: dbaryshkov@gmail.com
|
||||
|
|
@ -716,7 +721,7 @@ W: http://sourceforge.net/projects/acpi4asus
|
|||
W: http://xf.iksaif.net/acpi4asus
|
||||
S: Maintained
|
||||
|
||||
ASYNCHRONOUS TRANSFERS/TRANSFORMS API
|
||||
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
|
||||
P: Dan Williams
|
||||
M: dan.j.williams@intel.com
|
||||
P: Maciej Sosnowski
|
||||
|
|
@ -738,6 +743,8 @@ P: Nick Kossifidis
|
|||
M: mickflemm@gmail.com
|
||||
P: Luis R. Rodriguez
|
||||
M: mcgrof@gmail.com
|
||||
P: Bob Copeland
|
||||
M: me@bobcopeland.com
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ath5k-devel@lists.ath5k.org
|
||||
S: Maintained
|
||||
|
|
@ -772,6 +779,7 @@ ATM
|
|||
P: Chas Williams
|
||||
M: chas@cmf.nrl.navy.mil
|
||||
L: linux-atm-general@lists.sourceforge.net (subscribers-only)
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://linux-atm.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
|
|
@ -1519,10 +1527,10 @@ W: http://ebtables.sourceforge.net/
|
|||
S: Maintained
|
||||
|
||||
ECRYPT FILE SYSTEM
|
||||
P: Mike Halcrow, Phillip Hellewell
|
||||
M: mhalcrow@us.ibm.com, phillip@hellewell.homeip.net
|
||||
L: ecryptfs-devel@lists.sourceforge.net
|
||||
W: http://ecryptfs.sourceforge.net/
|
||||
P: Tyler Hicks, Dustin Kirkland
|
||||
M: tyhicks@linux.vnet.ibm.com, kirkland@canonical.com
|
||||
L: ecryptfs-devel@lists.launchpad.net
|
||||
W: https://launchpad.net/ecryptfs
|
||||
S: Supported
|
||||
|
||||
EDAC-CORE
|
||||
|
|
@ -1749,7 +1757,7 @@ FREESCALE I2C CPM DRIVER
|
|||
P: Jochen Friedrich
|
||||
M: jochen@scram.de
|
||||
L: linuxppc-dev@ozlabs.org
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
FREESCALE SOC FS_ENET DRIVER
|
||||
|
|
@ -1802,7 +1810,7 @@ S: Maintained
|
|||
|
||||
FTRACE
|
||||
P: Steven Rostedt
|
||||
M: srostedt@redhat.com
|
||||
M: rostedt@goodmis.org
|
||||
S: Maintained
|
||||
|
||||
FUJITSU FR-V (FRV) PORT
|
||||
|
|
@ -1872,6 +1880,37 @@ M: linux-kernel@vger.kernel.org
|
|||
W: http://www.kernel.org/pub/linux/kernel/people/rml/hdaps/
|
||||
S: Maintained
|
||||
|
||||
GSPCA FINEPIX SUBDRIVER
|
||||
P: Frank Zago
|
||||
M: frank@zago.net
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
GSPCA M5602 SUBDRIVER
|
||||
P: Erik Andren
|
||||
M: erik.andren@gmail.com
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
GSPCA PAC207 SONIXB SUBDRIVER
|
||||
P: Hans de Goede
|
||||
M: hdegoede@redhat.com
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
GSPCA T613 SUBDRIVER
|
||||
P: Leandro Costantino
|
||||
M: lcostantino@gmail.com
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
GSPCA USB WEBCAM DRIVER
|
||||
P: Jean-Francois Moine
|
||||
M: moinejf@free.fr
|
||||
W: http://moinejf.free.fr
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
HARDWARE MONITORING
|
||||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
|
|
@ -2022,7 +2061,7 @@ S: Maintained
|
|||
I2C/SMBUS STUB DRIVER
|
||||
P: Mark M. Hoffman
|
||||
M: mhoffman@lightlink.com
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
I2C SUBSYSTEM
|
||||
|
|
@ -2030,14 +2069,14 @@ P: Jean Delvare (PC drivers, core)
|
|||
M: khali@linux-fr.org
|
||||
P: Ben Dooks (embedded platforms)
|
||||
M: ben-linux@fluff.org
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
|
||||
S: Maintained
|
||||
|
||||
I2C-TINY-USB DRIVER
|
||||
P: Till Harbaum
|
||||
M: till@harbaum.org
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
T: http://www.harbaum.org/till/i2c_tiny_usb
|
||||
S: Maintained
|
||||
|
||||
|
|
@ -2152,9 +2191,9 @@ S: Supported
|
|||
|
||||
INOTIFY
|
||||
P: John McCutchan
|
||||
M: ttb@tentacle.dhs.org
|
||||
M: john@johnmccutchan.com
|
||||
P: Robert Love
|
||||
M: rml@novell.com
|
||||
M: rlove@rlove.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
|
|
@ -2178,6 +2217,13 @@ M: adaplas@gmail.com
|
|||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
||||
INTEL MENLOW THERMAL DRIVER
|
||||
P: Sujith Thomas
|
||||
M: sujith.thomas@intel.com
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
INTEL IA32 MICROCODE UPDATE SUPPORT
|
||||
P: Tigran Aivazian
|
||||
M: tigran@aivazian.fsnet.co.uk
|
||||
|
|
@ -2658,6 +2704,11 @@ P: Arnaldo Carvalho de Melo
|
|||
M: acme@ghostprotocols.net
|
||||
S: Maintained
|
||||
|
||||
LIS3LV02D ACCELEROMETER DRIVER
|
||||
P: Eric Piel
|
||||
M: eric.piel@tremplin-utc.net
|
||||
S: Maintained
|
||||
|
||||
LM83 HARDWARE MONITOR DRIVER
|
||||
P: Jean Delvare
|
||||
M: khali@linux-fr.org
|
||||
|
|
@ -2701,6 +2752,16 @@ M: matthew@wil.cx
|
|||
L: linux-scsi@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
LTP (Linux Test Project)
|
||||
P: Subrata Modak
|
||||
M: subrata@linux.vnet.ibm.com
|
||||
P: Mike Frysinger
|
||||
M: vapier@gentoo.org
|
||||
L: ltp-list@lists.sourceforge.net (subscribers-only)
|
||||
W: http://ltp.sourceforge.net/
|
||||
T: git kernel.org/pub/scm/linux/kernel/git/galak/ltp.git
|
||||
S: Maintained
|
||||
|
||||
M32R ARCHITECTURE
|
||||
P: Hirokazu Takata
|
||||
M: takata@linux-m32r.org
|
||||
|
|
@ -3143,7 +3204,7 @@ S: Maintained
|
|||
OPENCORES I2C BUS DRIVER
|
||||
P: Peter Korsgaard
|
||||
M: jacmet@sunsite.dk
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
OPROFILE
|
||||
|
|
@ -3190,7 +3251,7 @@ S: Maintained
|
|||
PA SEMI SMBUS DRIVER
|
||||
P: Olof Johansson
|
||||
M: olof@lixom.net
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
PANASONIC LAPTOP ACPI EXTRAS DRIVER
|
||||
|
|
@ -3329,13 +3390,15 @@ S: Maintained
|
|||
|
||||
PNP SUPPORT
|
||||
P: Adam Belay
|
||||
M: ambx1@neo.rr.com
|
||||
M: abelay@mit.edu
|
||||
P: Bjorn Helgaas
|
||||
M: bjorn.helgaas@hp.com
|
||||
S: Maintained
|
||||
|
||||
PNXxxxx I2C DRIVER
|
||||
P: Vitaly Wool
|
||||
M: vitalywool@gmail.com
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
PPP PROTOCOL DRIVERS AND COMPRESSORS
|
||||
|
|
@ -3696,6 +3759,15 @@ M: drzeus-sdhci@drzeus.cx
|
|||
L: sdhci-devel@list.drzeus.cx
|
||||
S: Maintained
|
||||
|
||||
SECURITY SUBSYSTEM
|
||||
F: security/
|
||||
P: James Morris
|
||||
M: jmorris@namei.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-security-module@vger.kernel.org (suggested Cc:)
|
||||
T: git kernel.org:pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
|
||||
S: Supported
|
||||
|
||||
SECURITY CONTACT
|
||||
P: Security Officers
|
||||
M: security@kernel.org
|
||||
|
|
@ -3799,7 +3871,7 @@ S: Maintained
|
|||
SIS 96X I2C/SMBUS DRIVER
|
||||
P: Mark M. Hoffman
|
||||
M: mhoffman@lightlink.com
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
SIS FRAMEBUFFER DRIVER
|
||||
|
|
@ -3866,8 +3938,6 @@ M: bootc@bootc.net
|
|||
S: Maintained
|
||||
|
||||
SOFTWARE RAID (Multiple Disks) SUPPORT
|
||||
P: Ingo Molnar
|
||||
M: mingo@redhat.com
|
||||
P: Neil Brown
|
||||
M: neilb@suse.de
|
||||
L: linux-raid@vger.kernel.org
|
||||
|
|
@ -4175,7 +4245,7 @@ M: dedekind@infradead.org
|
|||
P: Adrian Hunter
|
||||
M: ext-adrian.hunter@nokia.com
|
||||
L: linux-mtd@lists.infradead.org
|
||||
T: git git://git.infradead.org/~dedekind/ubifs-2.6.git
|
||||
T: git git://git.infradead.org/ubifs-2.6.git
|
||||
W: http://www.linux-mtd.infradead.org/doc/ubifs.html
|
||||
S: Maintained
|
||||
|
||||
|
|
@ -4229,7 +4299,7 @@ P: Artem Bityutskiy
|
|||
M: dedekind@infradead.org
|
||||
W: http://www.linux-mtd.infradead.org/
|
||||
L: linux-mtd@lists.infradead.org
|
||||
T: git git://git.infradead.org/~dedekind/ubi-2.6.git
|
||||
T: git git://git.infradead.org/ubi-2.6.git
|
||||
S: Maintained
|
||||
|
||||
USB ACM DRIVER
|
||||
|
|
@ -4546,7 +4616,7 @@ S: Maintained
|
|||
VIAPRO SMBUS DRIVER
|
||||
P: Jean Delvare
|
||||
M: khali@linux-fr.org
|
||||
L: i2c@lm-sensors.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER
|
||||
|
|
|
|||
14
Makefile
14
Makefile
|
|
@ -1,8 +1,8 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 28
|
||||
EXTRAVERSION = -rc2
|
||||
NAME = Killer Bat of Doom
|
||||
EXTRAVERSION = -rc9
|
||||
NAME = Erotic Pickled Herring
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
|
@ -536,7 +536,7 @@ KBUILD_CFLAGS += -g
|
|||
KBUILD_AFLAGS += -gdwarf-2
|
||||
endif
|
||||
|
||||
ifdef CONFIG_FTRACE
|
||||
ifdef CONFIG_FUNCTION_TRACER
|
||||
KBUILD_CFLAGS += -pg
|
||||
endif
|
||||
|
||||
|
|
@ -961,6 +961,7 @@ export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
|
|||
|
||||
# The asm symlink changes when $(ARCH) changes.
|
||||
# Detect this and ask user to run make mrproper
|
||||
# If asm is a stale symlink (point to dir that does not exist) remove it
|
||||
define check-symlink
|
||||
set -e; \
|
||||
if [ -L include/asm ]; then \
|
||||
|
|
@ -970,6 +971,10 @@ define check-symlink
|
|||
echo " set ARCH or save .config and run 'make mrproper' to fix it"; \
|
||||
exit 1; \
|
||||
fi; \
|
||||
test -e $$asmlink || rm include/asm; \
|
||||
elif [ -d include/asm ]; then \
|
||||
echo "ERROR: $@ is a directory but a symlink was expected";\
|
||||
exit 1; \
|
||||
fi
|
||||
endef
|
||||
|
||||
|
|
@ -1431,7 +1436,8 @@ ALLSOURCE_ARCHS := $(SRCARCH)
|
|||
define find-sources
|
||||
( for arch in $(ALLSOURCE_ARCHS) ; do \
|
||||
find $(__srctree)arch/$${arch} $(RCS_FIND_IGNORE) \
|
||||
-name $1 -print; \
|
||||
-wholename $(__srctree)arch/$${arch}/include/asm -type d -prune \
|
||||
-o -name $1 -print; \
|
||||
done ; \
|
||||
find $(__srctree)security/selinux/include $(RCS_FIND_IGNORE) \
|
||||
-name $1 -print; \
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ config OPROFILE_IBS
|
|||
Instruction-Based Sampling (IBS) is a new profiling
|
||||
technique that provides rich, precise program performance
|
||||
information. IBS is introduced by AMD Family10h processors
|
||||
(AMD Opteron Quad-Core processor “Barcelona”) to overcome
|
||||
(AMD Opteron Quad-Core processor "Barcelona") to overcome
|
||||
the limitations of conventional performance counter
|
||||
sampling.
|
||||
|
||||
|
|
@ -79,8 +79,6 @@ config HAVE_KRETPROBES
|
|||
# task_pt_regs() in asm/processor.h or asm/ptrace.h
|
||||
# arch_has_single_step() if there is hardware single-step support
|
||||
# arch_has_block_step() if there is hardware block-step support
|
||||
# arch_ptrace() and not #define __ARCH_SYS_PTRACE
|
||||
# compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE
|
||||
# asm/syscall.h supplying asm-generic/syscall.h interface
|
||||
# linux/regset.h user_regset interfaces
|
||||
# CORE_DUMP_USE_REGSET #define'd in linux/elf.h
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче