You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit 'v2.6.28-rc6' into irq/urgent
This commit is contained in:
+4
-40
@@ -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/
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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,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
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
+72
-97
@@ -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
|
||||
@@ -1003,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
|
||||
# | | | | |
|
||||
@@ -1040,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
|
||||
@@ -1077,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
|
||||
@@ -1251,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
|
||||
----------
|
||||
|
||||
@@ -1289,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
|
||||
# | | | | |
|
||||
@@ -1317,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
|
||||
@@ -1334,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.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user