Merge branch 'poll' into staging/for_v3.4
* poll: (5970 commits) poll: add poll_requested_events() and poll_does_not_wait() functions crc32: select an algorithm via Kconfig crc32: add self-test code for crc32c crypto: crc32c should use library implementation crc32: bolt on crc32c crc32: add note about this patchset to crc32.c crc32: optimize loop counter for x86 crc32: add slice-by-8 algorithm to existing code crc32: make CRC_*_BITS definition correspond to actual bit counts crc32: fix mixing of endian-specific types crc32: miscellaneous cleanups crc32: simplify unit test code crc32: move long comment about crc32 fundamentals to Documentation/ crc32: remove two instances of trailing whitespaces checkpatch: check for quoted strings broken across lines checkpatch: whitespace - add/remove blank lines checkpatch: warn on use of yield() checkpatch: add --strict tests for braces, comments and casts checkpatch: add [] to type extensions checkpatch: high precedence operators do not require additional parentheses in #defines ...
This commit is contained in:
Mauro Carvalho Chehab
commit
50953e0640
|
|
@ -7,8 +7,8 @@ Please try and keep the descriptions small enough to fit on one line.
|
|||
|
||||
Following translations are available on the WWW:
|
||||
|
||||
- Japanese, maintained by the JF Project (JF@linux.or.jp), at
|
||||
http://www.linux.or.jp/JF/
|
||||
- Japanese, maintained by the JF Project (jf@listserv.linux.or.jp), at
|
||||
http://linuxjf.sourceforge.jp/
|
||||
|
||||
00-INDEX
|
||||
- this file.
|
||||
|
|
@ -104,6 +104,8 @@ cpuidle/
|
|||
- info on CPU_IDLE, CPU idle state management subsystem.
|
||||
cputopology.txt
|
||||
- documentation on how CPU topology info is exported via sysfs.
|
||||
crc32.txt
|
||||
- brief tutorial on CRC computation
|
||||
cris/
|
||||
- directory with info about Linux on CRIS architecture.
|
||||
crypto/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Date: 09-Jul-2007
|
|||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file is deprecated and sheduled to be removed in 2014,
|
||||
This file is deprecated and scheduled to be removed in 2014,
|
||||
because its not possible to express the 'soft and hard block'
|
||||
state of the rfkill driver.
|
||||
Values: A numeric value.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: devfs
|
||||
Date: July 2005 (scheduled), finally removed in kernel v2.6.18
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
devfs has been unmaintained for a number of years, has unfixable
|
||||
races, contains a naming policy within the kernel that is
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
|
|
@ -15,7 +15,7 @@ Description:
|
|||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
|
|
@ -29,7 +29,7 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermChar
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file is the TermChar value to be sent to the USB TMC
|
||||
device as described by the document, "Universal Serial Bus Test
|
||||
|
|
@ -42,7 +42,7 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the TermChar is to be sent to the
|
||||
device on every transaction or not. For more details about
|
||||
|
|
@ -53,7 +53,7 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the the transaction of the USB TMC
|
||||
device is to be automatically aborted if there is any error.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Description:
|
|||
The name of the module that is in the kernel. This
|
||||
module name will show up either if the module is built
|
||||
directly into the kernel, or if it is loaded as a
|
||||
dyanmic module.
|
||||
dynamic module.
|
||||
|
||||
/sys/module/MODULENAME/parameters
|
||||
This directory contains individual files that are each
|
||||
|
|
|
|||
|
|
@ -182,3 +182,14 @@ Description:
|
|||
USB2 hardware LPM is enabled for the device. Developer can
|
||||
write y/Y/1 or n/N/0 to the file to enable/disable the
|
||||
feature.
|
||||
|
||||
What: /sys/bus/usb/devices/.../removable
|
||||
Date: February 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
Some information about whether a given USB device is
|
||||
physically fixed to the platform can be inferred from a
|
||||
combination of hub decriptor bits and platform-specific data
|
||||
such as ACPI. This file will read either "removable" or
|
||||
"fixed" if the information is available, and "unknown"
|
||||
otherwise.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/class/
|
||||
Date: Febuary 2006
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
The /sys/class directory will consist of a group of
|
||||
subdirectories describing individual classes of devices
|
||||
|
|
|
|||
|
|
@ -65,6 +65,13 @@ Description:
|
|||
Defines the penalty which will be applied to an
|
||||
originator message's tq-field on every hop.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
|
||||
Date: Dec 2011
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Defines the routing procotol this mesh instance
|
||||
uses to find the optimal paths through the mesh.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/devices
|
||||
Date: February 2006
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
The /sys/devices tree contains a snapshot of the
|
||||
internal state of the kernel device tree. Devices will
|
||||
|
|
|
|||
|
|
@ -165,3 +165,21 @@ Description:
|
|||
|
||||
Not all drivers support this attribute. If it isn't supported,
|
||||
attempts to read or write it will yield I/O errors.
|
||||
|
||||
What: /sys/devices/.../power/pm_qos_latency_us
|
||||
Date: March 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
|
||||
contains the PM QoS resume latency limit for the given device,
|
||||
which is the maximum allowed time it can take to resume the
|
||||
device, after it has been suspended at run time, from a resume
|
||||
request to the moment the device will be ready to process I/O,
|
||||
in microseconds. If it is equal to 0, however, this means that
|
||||
the PM QoS resume latency may be arbitrary.
|
||||
|
||||
Not all drivers support this attribute. If it isn't supported,
|
||||
it is not present.
|
||||
|
||||
This attribute has no effect on system-wide suspend/resume and
|
||||
hibernation.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,58 @@
|
|||
What: /sys/devices/socX
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/devices/ directory contains a sub-directory for each
|
||||
System-on-Chip (SoC) device on a running platform. Information
|
||||
regarding each SoC can be obtained by reading sysfs files. This
|
||||
functionality is only available if implemented by the platform.
|
||||
|
||||
The directory created for each SoC will also house information
|
||||
about devices which are commonly contained in /sys/devices/platform.
|
||||
It has been agreed that if an SoC device exists, its supported
|
||||
devices would be better suited to appear as children of that SoC.
|
||||
|
||||
What: /sys/devices/socX/machine
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains the SoC machine
|
||||
name (e.g. Ux500).
|
||||
|
||||
What: /sys/devices/socX/family
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains SoC family name
|
||||
(e.g. DB8500).
|
||||
|
||||
What: /sys/devices/socX/soc_id
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. In the case of
|
||||
ST-Ericsson's chips this contains the SoC serial number.
|
||||
|
||||
What: /sys/devices/socX/revision
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. Contains the SoC's
|
||||
manufacturing revision number.
|
||||
|
||||
What: /sys/devices/socX/process
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported ST-Ericsson's silicon. Contains the
|
||||
the process by which the silicon chip was manufactured.
|
||||
|
||||
What: /sys/bus/soc
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/bus/soc/ directory contains the usual sub-folders
|
||||
expected under most buses. /sys/bus/soc/devices is of particular
|
||||
interest, as it contains a symlink for each SoC device found on
|
||||
the system. Each symlink points back into the aforementioned
|
||||
/sys/devices/socX devices.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/devices/platform/samsung/performance_level
|
||||
Date: January 1, 2010
|
||||
KernelVersion: 2.6.33
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description: Some Samsung laptops have different "performance levels"
|
||||
that are can be modified by a function key, and by this
|
||||
sysfs file. These values don't always make a whole lot
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
What: /sys/kernel/mm/cleancache/
|
||||
Date: April 2011
|
||||
Contact: Dan Magenheimer <dan.magenheimer@oracle.com>
|
||||
Description:
|
||||
/sys/kernel/mm/cleancache/ contains a number of files which
|
||||
record a count of various cleancache operations
|
||||
(sum across all filesystems):
|
||||
succ_gets
|
||||
failed_gets
|
||||
puts
|
||||
flushes
|
||||
|
|
@ -129,7 +129,6 @@
|
|||
!Finclude/net/cfg80211.h cfg80211_pmksa
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
|
||||
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
|
||||
!Finclude/net/cfg80211.h __cfg80211_auth_canceled
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
|
||||
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_send_deauth
|
||||
|
|
|
|||
|
|
@ -387,7 +387,7 @@ an example.
|
|||
<title>See also</title>
|
||||
<para>
|
||||
<citation>
|
||||
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
|
||||
<ulink url="http://kernel.org/pub/linux/kernel/people/sct/ext3/journal-design.ps.gz">
|
||||
Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie
|
||||
</ulink>
|
||||
</citation>
|
||||
|
|
|
|||
|
|
@ -361,6 +361,23 @@
|
|||
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
|
||||
</para>
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="kgdbreboot">
|
||||
<title>Run time parameter: kgdbreboot</title>
|
||||
<para> The kgdbreboot feature allows you to change how the debugger
|
||||
deals with the reboot notification. You have 3 choices for the
|
||||
behavior. The default behavior is always set to 0.</para>
|
||||
<orderedlist>
|
||||
<listitem><para>echo -1 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Ignore the reboot notification entirely.</para>
|
||||
</listitem>
|
||||
<listitem><para>echo 0 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Send the detach message to any attached debugger client.</para>
|
||||
</listitem>
|
||||
<listitem><para>echo 1 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Enter the debugger on reboot notify.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="usingKDB">
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@
|
|||
<para>
|
||||
The contents of this file are subject to the Open
|
||||
Software License version 1.1 that can be found at
|
||||
<ulink url="http://www.opensource.org/licenses/osl-1.1.txt">http://www.opensource.org/licenses/osl-1.1.txt</ulink> and is included herein
|
||||
by reference.
|
||||
<ulink url="http://fedoraproject.org/wiki/Licensing:OSL1.1">http://fedoraproject.org/wiki/Licensing:OSL1.1</ulink>
|
||||
and is included herein by reference.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -945,7 +945,7 @@ and other resources, etc.
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
!BSY && ERR after CDB tranfer starts but before the
|
||||
!BSY && ERR after CDB transfer starts but before the
|
||||
last byte of CDB is transferred. ATA/ATAPI standard states
|
||||
that "The device shall not terminate the PACKET command
|
||||
with an error before the last byte of the command packet has
|
||||
|
|
@ -1050,7 +1050,7 @@ and other resources, etc.
|
|||
to complete a command. Combined with the fact that MWDMA
|
||||
and PIO transfer errors aren't allowed to use ICRC bit up to
|
||||
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
|
||||
indicate tranfer errors.
|
||||
indicate transfer errors.
|
||||
</para>
|
||||
<para>
|
||||
However, ATA/ATAPI-8 draft revision 1f removes the part
|
||||
|
|
|
|||
|
|
@ -444,7 +444,7 @@ linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entr
|
|||
<entry><para><link
|
||||
linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote>
|
||||
<para>Presumably all V4L RGB formats are
|
||||
little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue
|
||||
little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue
|
||||
swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
|
||||
</footnote></para></entry>
|
||||
</row>
|
||||
|
|
@ -823,7 +823,7 @@ standard); 35468950 Hz PAL and SECAM (625-line standards)</entry>
|
|||
<row>
|
||||
<entry>sample_format</entry>
|
||||
<entry>V4L2_PIX_FMT_GREY. The last four bytes (a
|
||||
machine endianess integer) contain a frame counter.</entry>
|
||||
machine endianness integer) contain a frame counter.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start[]</entry>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
|
||||
|
||||
Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 65000 /* kHz */
|
||||
#define XPIX 1024
|
||||
#define YPIX 768
|
||||
#define XY_RATIO XY_RATIO_4_3
|
||||
#define XBLANK 320
|
||||
#define YBLANK 38
|
||||
#define XOFFSET 8
|
||||
#define XPULSE 144
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux XGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
|
||||
#define HSYNC_POL 0
|
||||
#define VSYNC_POL 0
|
||||
#define CRC 0x55
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
|
||||
|
||||
Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 108000 /* kHz */
|
||||
#define XPIX 1280
|
||||
#define YPIX 1024
|
||||
#define XY_RATIO XY_RATIO_5_4
|
||||
#define XBLANK 408
|
||||
#define YBLANK 42
|
||||
#define XOFFSET 48
|
||||
#define XPULSE 112
|
||||
#define YOFFSET (63+1)
|
||||
#define YPULSE (63+3)
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux SXGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0xa0
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1680x1050.S: EDID data set for standard 1680x1050 60 Hz monitor
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 146250 /* kHz */
|
||||
#define XPIX 1680
|
||||
#define YPIX 1050
|
||||
#define XY_RATIO XY_RATIO_16_10
|
||||
#define XBLANK 560
|
||||
#define YBLANK 39
|
||||
#define XOFFSET 104
|
||||
#define XPULSE 176
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux WSXGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x26
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1920x1080.S: EDID data set for standard 1920x1080 60 Hz monitor
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 148500 /* kHz */
|
||||
#define XPIX 1920
|
||||
#define YPIX 1080
|
||||
#define XY_RATIO XY_RATIO_16_9
|
||||
#define XBLANK 280
|
||||
#define YBLANK 45
|
||||
#define XOFFSET 88
|
||||
#define XPULSE 44
|
||||
#define YOFFSET (63+4)
|
||||
#define YPULSE (63+5)
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux FHD"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x05
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
In the good old days when graphics parameters were configured explicitly
|
||||
in a file called xorg.conf, even broken hardware could be managed.
|
||||
|
||||
Today, with the advent of Kernel Mode Setting, a graphics board is
|
||||
either correctly working because all components follow the standards -
|
||||
or the computer is unusable, because the screen remains dark after
|
||||
booting or it displays the wrong area. Cases when this happens are:
|
||||
- The graphics board does not recognize the monitor.
|
||||
- The graphics board is unable to detect any EDID data.
|
||||
- The graphics board incorrectly forwards EDID data to the driver.
|
||||
- The monitor sends no or bogus EDID data.
|
||||
- A KVM sends its own EDID data instead of querying the connected monitor.
|
||||
Adding the kernel parameter "nomodeset" helps in most cases, but causes
|
||||
restrictions later on.
|
||||
|
||||
As a remedy for such situations, the kernel configuration item
|
||||
CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
|
||||
individually prepared or corrected EDID data set in the /lib/firmware
|
||||
directory from where it is loaded via the firmware interface. The code
|
||||
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
|
||||
commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
|
||||
1920x1080) as binary blobs, but the kernel source tree does not contain
|
||||
code to create these data. In order to elucidate the origin of the
|
||||
built-in binary EDID blobs and to facilitate the creation of individual
|
||||
data for a specific misbehaving monitor, commented sources and a
|
||||
Makefile environment are given here.
|
||||
|
||||
To create binary EDID and C source code files from the existing data
|
||||
material, simply type "make".
|
||||
|
||||
If you want to create your own EDID file, copy the file 1024x768.S and
|
||||
replace the settings with your own data. The CRC value in the last line
|
||||
#define CRC 0x55
|
||||
is a bit tricky. After a first version of the binary data set is
|
||||
created, it must be be checked with the "edid-decode" utility which will
|
||||
most probably complain about a wrong CRC. Fortunately, the utility also
|
||||
displays the correct CRC which must then be inserted into the source
|
||||
file. After the make procedure is repeated, the EDID data set is ready
|
||||
to be used.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
|
||||
SOURCES := $(wildcard [0-9]*x[0-9]*.S)
|
||||
|
||||
BIN := $(patsubst %.S, %.bin, $(SOURCES))
|
||||
|
||||
IHEX := $(patsubst %.S, %.bin.ihex, $(SOURCES))
|
||||
|
||||
CODE := $(patsubst %.S, %.c, $(SOURCES))
|
||||
|
||||
all: $(BIN) $(IHEX) $(CODE)
|
||||
|
||||
clean:
|
||||
@rm -f *.o *.bin.ihex *.bin *.c
|
||||
|
||||
%.o: %.S
|
||||
@cc -c $^
|
||||
|
||||
%.bin: %.o
|
||||
@objcopy -Obinary $^ $@
|
||||
|
||||
%.bin.ihex: %.o
|
||||
@objcopy -Oihex $^ $@
|
||||
@dos2unix $@ 2>/dev/null
|
||||
|
||||
%.c: %.bin
|
||||
@echo "{" >$@; hexdump -f hex $^ >>$@; echo "};" >>$@
|
||||
|
|
@ -0,0 +1,261 @@
|
|||
/*
|
||||
edid.S: EDID data template
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
|
||||
/* Manufacturer */
|
||||
#define MFG_LNX1 'L'
|
||||
#define MFG_LNX2 'N'
|
||||
#define MFG_LNX3 'X'
|
||||
#define SERIAL 0
|
||||
#define YEAR 2012
|
||||
#define WEEK 5
|
||||
|
||||
/* EDID 1.3 standard definitions */
|
||||
#define XY_RATIO_16_10 0b00
|
||||
#define XY_RATIO_4_3 0b01
|
||||
#define XY_RATIO_5_4 0b10
|
||||
#define XY_RATIO_16_9 0b11
|
||||
|
||||
#define mfgname2id(v1,v2,v3) \
|
||||
((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
|
||||
#define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
|
||||
#define msbs2(v1,v2) ((((v1>>8)&0x0f)<<4)+((v2>>8)&0x0f))
|
||||
#define msbs4(v1,v2,v3,v4) \
|
||||
(((v1&0x03)>>2)+((v2&0x03)>>4)+((v3&0x03)>>6)+((v4&0x03)>>8))
|
||||
#define pixdpi2mm(pix,dpi) ((pix*25)/dpi)
|
||||
#define xsize pixdpi2mm(XPIX,DPI)
|
||||
#define ysize pixdpi2mm(YPIX,DPI)
|
||||
|
||||
.data
|
||||
|
||||
/* Fixed header pattern */
|
||||
header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00
|
||||
|
||||
mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
|
||||
|
||||
prod_code: .word 0
|
||||
|
||||
/* Serial number. 32 bits, little endian. */
|
||||
serial_number: .long SERIAL
|
||||
|
||||
/* Week of manufacture */
|
||||
week: .byte WEEK
|
||||
|
||||
/* Year of manufacture, less 1990. (1990-2245)
|
||||
If week=255, it is the model year instead */
|
||||
year: .byte YEAR-1990
|
||||
|
||||
version: .byte VERSION /* EDID version, usually 1 (for 1.3) */
|
||||
revision: .byte REVISION /* EDID revision, usually 3 (for 1.3) */
|
||||
|
||||
/* If Bit 7=1 Digital input. If set, the following bit definitions apply:
|
||||
Bits 6-1 Reserved, must be 0
|
||||
Bit 0 Signal is compatible with VESA DFP 1.x TMDS CRGB,
|
||||
1 pixel per clock, up to 8 bits per color, MSB aligned,
|
||||
If Bit 7=0 Analog input. If clear, the following bit definitions apply:
|
||||
Bits 6-5 Video white and sync levels, relative to blank
|
||||
00=+0.7/-0.3 V; 01=+0.714/-0.286 V;
|
||||
10=+1.0/-0.4 V; 11=+0.7/0 V
|
||||
Bit 4 Blank-to-black setup (pedestal) expected
|
||||
Bit 3 Separate sync supported
|
||||
Bit 2 Composite sync (on HSync) supported
|
||||
Bit 1 Sync on green supported
|
||||
Bit 0 VSync pulse must be serrated when somposite or
|
||||
sync-on-green is used. */
|
||||
video_parms: .byte 0x6d
|
||||
|
||||
/* Maximum horizontal image size, in centimetres
|
||||
(max 292 cm/115 in at 16:9 aspect ratio) */
|
||||
max_hor_size: .byte xsize/10
|
||||
|
||||
/* Maximum vertical image size, in centimetres.
|
||||
If either byte is 0, undefined (e.g. projector) */
|
||||
max_vert_size: .byte ysize/10
|
||||
|
||||
/* Display gamma, minus 1, times 100 (range 1.00-3.5 */
|
||||
gamma: .byte 120
|
||||
|
||||
/* Bit 7 DPMS standby supported
|
||||
Bit 6 DPMS suspend supported
|
||||
Bit 5 DPMS active-off supported
|
||||
Bits 4-3 Display type: 00=monochrome; 01=RGB colour;
|
||||
10=non-RGB multicolour; 11=undefined
|
||||
Bit 2 Standard sRGB colour space. Bytes 25-34 must contain
|
||||
sRGB standard values.
|
||||
Bit 1 Preferred timing mode specified in descriptor block 1.
|
||||
Bit 0 GTF supported with default parameter values. */
|
||||
dsp_features: .byte 0xea
|
||||
|
||||
/* Chromaticity coordinates. */
|
||||
/* Red and green least-significant bits
|
||||
Bits 7-6 Red x value least-significant 2 bits
|
||||
Bits 5-4 Red y value least-significant 2 bits
|
||||
Bits 3-2 Green x value lst-significant 2 bits
|
||||
Bits 1-0 Green y value least-significant 2 bits */
|
||||
red_green_lsb: .byte 0x5e
|
||||
|
||||
/* Blue and white least-significant 2 bits */
|
||||
blue_white_lsb: .byte 0xc0
|
||||
|
||||
/* Red x value most significant 8 bits.
|
||||
0-255 encodes 0-0.996 (255/256); 0-0.999 (1023/1024) with lsbits */
|
||||
red_x_msb: .byte 0xa4
|
||||
|
||||
/* Red y value most significant 8 bits */
|
||||
red_y_msb: .byte 0x59
|
||||
|
||||
/* Green x and y value most significant 8 bits */
|
||||
green_x_y_msb: .byte 0x4a,0x98
|
||||
|
||||
/* Blue x and y value most significant 8 bits */
|
||||
blue_x_y_msb: .byte 0x25,0x20
|
||||
|
||||
/* Default white point x and y value most significant 8 bits */
|
||||
white_x_y_msb: .byte 0x50,0x54
|
||||
|
||||
/* Established timings */
|
||||
/* Bit 7 720x400 @ 70 Hz
|
||||
Bit 6 720x400 @ 88 Hz
|
||||
Bit 5 640x480 @ 60 Hz
|
||||
Bit 4 640x480 @ 67 Hz
|
||||
Bit 3 640x480 @ 72 Hz
|
||||
Bit 2 640x480 @ 75 Hz
|
||||
Bit 1 800x600 @ 56 Hz
|
||||
Bit 0 800x600 @ 60 Hz */
|
||||
estbl_timing1: .byte 0x00
|
||||
|
||||
/* Bit 7 800x600 @ 72 Hz
|
||||
Bit 6 800x600 @ 75 Hz
|
||||
Bit 5 832x624 @ 75 Hz
|
||||
Bit 4 1024x768 @ 87 Hz, interlaced (1024x768)
|
||||
Bit 3 1024x768 @ 60 Hz
|
||||
Bit 2 1024x768 @ 72 Hz
|
||||
Bit 1 1024x768 @ 75 Hz
|
||||
Bit 0 1280x1024 @ 75 Hz */
|
||||
estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS
|
||||
|
||||
/* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II)
|
||||
Bits 6-0 Other manufacturer-specific display mod */
|
||||
estbl_timing3: .byte 0x00
|
||||
|
||||
/* Standard timing */
|
||||
/* X resolution, less 31, divided by 8 (256-2288 pixels) */
|
||||
std_xres: .byte (XPIX/8)-31
|
||||
/* Y resolution, X:Y pixel ratio
|
||||
Bits 7-6 X:Y pixel ratio: 00=16:10; 01=4:3; 10=5:4; 11=16:9.
|
||||
Bits 5-0 Vertical frequency, less 60 (60-123 Hz) */
|
||||
std_vres: .byte (XY_RATIO<<6)+VFREQ-60
|
||||
.fill 7,2,0x0101 /* Unused */
|
||||
|
||||
descriptor1:
|
||||
/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
|
||||
clock: .word CLOCK/10
|
||||
|
||||
/* Horizontal active pixels 8 lsbits (0-4095) */
|
||||
x_act_lsb: .byte XPIX&0xff
|
||||
/* Horizontal blanking pixels 8 lsbits (0-4095)
|
||||
End of active to start of next active. */
|
||||
x_blk_lsb: .byte XBLANK&0xff
|
||||
/* Bits 7-4 Horizontal active pixels 4 msbits
|
||||
Bits 3-0 Horizontal blanking pixels 4 msbits */
|
||||
x_msbs: .byte msbs2(XPIX,XBLANK)
|
||||
|
||||
/* Vertical active lines 8 lsbits (0-4095) */
|
||||
y_act_lsb: .byte YPIX&0xff
|
||||
/* Vertical blanking lines 8 lsbits (0-4095) */
|
||||
y_blk_lsb: .byte YBLANK&0xff
|
||||
/* Bits 7-4 Vertical active lines 4 msbits
|
||||
Bits 3-0 Vertical blanking lines 4 msbits */
|
||||
y_msbs: .byte msbs2(YPIX,YBLANK)
|
||||
|
||||
/* Horizontal sync offset pixels 8 lsbits (0-1023) From blanking start */
|
||||
x_snc_off_lsb: .byte XOFFSET&0xff
|
||||
/* Horizontal sync pulse width pixels 8 lsbits (0-1023) */
|
||||
x_snc_pls_lsb: .byte XPULSE&0xff
|
||||
/* Bits 7-4 Vertical sync offset lines 4 lsbits -63)
|
||||
Bits 3-0 Vertical sync pulse width lines 4 lsbits -63) */
|
||||
y_snc_lsb: .byte ((YOFFSET-63)<<4)+(YPULSE-63)
|
||||
/* Bits 7-6 Horizontal sync offset pixels 2 msbits
|
||||
Bits 5-4 Horizontal sync pulse width pixels 2 msbits
|
||||
Bits 3-2 Vertical sync offset lines 2 msbits
|
||||
Bits 1-0 Vertical sync pulse width lines 2 msbits */
|
||||
xy_snc_msbs: .byte msbs4(XOFFSET,XPULSE,YOFFSET,YPULSE)
|
||||
|
||||
/* Horizontal display size, mm, 8 lsbits (0-4095 mm, 161 in) */
|
||||
x_dsp_size: .byte xsize&0xff
|
||||
|
||||
/* Vertical display size, mm, 8 lsbits (0-4095 mm, 161 in) */
|
||||
y_dsp_size: .byte ysize&0xff
|
||||
|
||||
/* Bits 7-4 Horizontal display size, mm, 4 msbits
|
||||
Bits 3-0 Vertical display size, mm, 4 msbits */
|
||||
dsp_size_mbsb: .byte msbs2(xsize,ysize)
|
||||
|
||||
/* Horizontal border pixels (each side; total is twice this) */
|
||||
x_border: .byte 0
|
||||
/* Vertical border lines (each side; total is twice this) */
|
||||
y_border: .byte 0
|
||||
|
||||
/* Bit 7 Interlaced
|
||||
Bits 6-5 Stereo mode: 00=No stereo; other values depend on bit 0:
|
||||
Bit 0=0: 01=Field sequential, sync=1 during right; 10=similar,
|
||||
sync=1 during left; 11=4-way interleaved stereo
|
||||
Bit 0=1 2-way interleaved stereo: 01=Right image on even lines;
|
||||
10=Left image on even lines; 11=side-by-side
|
||||
Bits 4-3 Sync type: 00=Analog composite; 01=Bipolar analog composite;
|
||||
10=Digital composite (on HSync); 11=Digital separate
|
||||
Bit 2 If digital separate: Vertical sync polarity (1=positive)
|
||||
Other types: VSync serrated (HSync during VSync)
|
||||
Bit 1 If analog sync: Sync on all 3 RGB lines (else green only)
|
||||
Digital: HSync polarity (1=positive)
|
||||
Bit 0 2-way line-interleaved stereo, if bits 4-3 are not 00. */
|
||||
features: .byte 0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1)
|
||||
|
||||
descriptor2: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xff /* Descriptor is monitor serial number (text) */
|
||||
.byte 0 /* Must be zero */
|
||||
start1: .ascii "Linux #0"
|
||||
end1: .byte 0x0a /* End marker */
|
||||
.fill 12-(end1-start1), 1, 0x20 /* Padded spaces */
|
||||
descriptor3: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xfd /* Descriptor is monitor range limits */
|
||||
.byte 0 /* Must be zero */
|
||||
start2: .byte VFREQ-1 /* Minimum vertical field rate (1-255 Hz) */
|
||||
.byte VFREQ+1 /* Maximum vertical field rate (1-255 Hz) */
|
||||
.byte (CLOCK/(XPIX+XBLANK))-1 /* Minimum horizontal line rate
|
||||
(1-255 kHz) */
|
||||
.byte (CLOCK/(XPIX+XBLANK))+1 /* Maximum horizontal line rate
|
||||
(1-255 kHz) */
|
||||
.byte (CLOCK/10000)+1 /* Maximum pixel clock rate, rounded up
|
||||
to 10 MHz multiple (10-2550 MHz) */
|
||||
.byte 0 /* No extended timing information type */
|
||||
end2: .byte 0x0a /* End marker */
|
||||
.fill 12-(end2-start2), 1, 0x20 /* Padded spaces */
|
||||
descriptor4: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xfc /* Descriptor is text */
|
||||
.byte 0 /* Must be zero */
|
||||
start3: .ascii TIMING_NAME
|
||||
end3: .byte 0x0a /* End marker */
|
||||
.fill 12-(end3-start3), 1, 0x20 /* Padded spaces */
|
||||
extensions: .byte 0 /* Number of extensions to follow */
|
||||
checksum: .byte CRC /* Sum of all bytes must be 0 */
|
||||
|
|
@ -0,0 +1 @@
|
|||
"\t" 8/1 "0x%02x, " "\n"
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
irq_domain interrupt number mapping library
|
||||
|
||||
The current design of the Linux kernel uses a single large number
|
||||
space where each separate IRQ source is assigned a different number.
|
||||
This is simple when there is only one interrupt controller, but in
|
||||
systems with multiple interrupt controllers the kernel must ensure
|
||||
that each one gets assigned non-overlapping allocations of Linux
|
||||
IRQ numbers.
|
||||
|
||||
The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
|
||||
irq numbers, but they don't provide any support for reverse mapping of
|
||||
the controller-local IRQ (hwirq) number into the Linux IRQ number
|
||||
space.
|
||||
|
||||
The irq_domain library adds mapping between hwirq and IRQ numbers on
|
||||
top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
|
||||
preferred over interrupt controller drivers open coding their own
|
||||
reverse mapping scheme.
|
||||
|
||||
irq_domain also implements translation from Device Tree interrupt
|
||||
specifiers to hwirq numbers, and can be easily extended to support
|
||||
other IRQ topology data sources.
|
||||
|
||||
=== irq_domain usage ===
|
||||
An interrupt controller driver creates and registers an irq_domain by
|
||||
calling one of the irq_domain_add_*() functions (each mapping method
|
||||
has a different allocator function, more on that later). The function
|
||||
will return a pointer to the irq_domain on success. The caller must
|
||||
provide the allocator function with an irq_domain_ops structure with
|
||||
the .map callback populated as a minimum.
|
||||
|
||||
In most cases, the irq_domain will begin empty without any mappings
|
||||
between hwirq and IRQ numbers. Mappings are added to the irq_domain
|
||||
by calling irq_create_mapping() which accepts the irq_domain and a
|
||||
hwirq number as arguments. If a mapping for the hwirq doesn't already
|
||||
exist then it will allocate a new Linux irq_desc, associate it with
|
||||
the hwirq, and call the .map() callback so the driver can perform any
|
||||
required hardware setup.
|
||||
|
||||
When an interrupt is received, irq_find_mapping() function should
|
||||
be used to find the Linux IRQ number from the hwirq number.
|
||||
|
||||
If the driver has the Linux IRQ number or the irq_data pointer, and
|
||||
needs to know the associated hwirq number (such as in the irq_chip
|
||||
callbacks) then it can be directly obtained from irq_data->hwirq.
|
||||
|
||||
=== Types of irq_domain mappings ===
|
||||
There are several mechanisms available for reverse mapping from hwirq
|
||||
to Linux irq, and each mechanism uses a different allocation function.
|
||||
Which reverse map type should be used depends on the use case. Each
|
||||
of the reverse map types are described below:
|
||||
|
||||
==== Linear ====
|
||||
irq_domain_add_linear()
|
||||
|
||||
The linear reverse map maintains a fixed size table indexed by the
|
||||
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
|
||||
the hwirq, and the IRQ number is stored in the table.
|
||||
|
||||
The Linear map is a good choice when the maximum number of hwirqs is
|
||||
fixed and a relatively small number (~ < 256). The advantages of this
|
||||
map are fixed time lookup for IRQ numbers, and irq_descs are only
|
||||
allocated for in-use IRQs. The disadvantage is that the table must be
|
||||
as large as the largest possible hwirq number.
|
||||
|
||||
The majority of drivers should use the linear map.
|
||||
|
||||
==== Tree ====
|
||||
irq_domain_add_tree()
|
||||
|
||||
The irq_domain maintains a radix tree map from hwirq numbers to Linux
|
||||
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
|
||||
hwirq is used as the lookup key for the radix tree.
|
||||
|
||||
The tree map is a good choice if the hwirq number can be very large
|
||||
since it doesn't need to allocate a table as large as the largest
|
||||
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
|
||||
dependent on how many entries are in the table.
|
||||
|
||||
Very few drivers should need this mapping. At the moment, powerpc
|
||||
iseries is the only user.
|
||||
|
||||
==== No Map ===-
|
||||
irq_domain_add_nomap()
|
||||
|
||||
The No Map mapping is to be used when the hwirq number is
|
||||
programmable in the hardware. In this case it is best to program the
|
||||
Linux IRQ number into the hardware itself so that no mapping is
|
||||
required. Calling irq_create_direct_mapping() will allocate a Linux
|
||||
IRQ number and call the .map() callback so that driver can program the
|
||||
Linux IRQ number into the hardware.
|
||||
|
||||
Most drivers cannot use this mapping.
|
||||
|
||||
==== Legacy ====
|
||||
irq_domain_add_legacy()
|
||||
irq_domain_add_legacy_isa()
|
||||
|
||||
The Legacy mapping is a special case for drivers that already have a
|
||||
range of irq_descs allocated for the hwirqs. It is used when the
|
||||
driver cannot be immediately converted to use the linear mapping. For
|
||||
example, many embedded system board support files use a set of #defines
|
||||
for IRQ numbers that are passed to struct device registrations. In that
|
||||
case the Linux IRQ numbers cannot be dynamically assigned and the legacy
|
||||
mapping should be used.
|
||||
|
||||
The legacy map assumes a contiguous range of IRQ numbers has already
|
||||
been allocated for the controller and that the IRQ number can be
|
||||
calculated by adding a fixed offset to the hwirq number, and
|
||||
visa-versa. The disadvantage is that it requires the interrupt
|
||||
controller to manage IRQ allocations and it requires an irq_desc to be
|
||||
allocated for every hwirq, even if it is unused.
|
||||
|
||||
The legacy map should only be used if fixed IRQ mappings must be
|
||||
supported. For example, ISA controllers would use the legacy map for
|
||||
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
|
||||
numbers.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -180,6 +180,20 @@ over a rather long period of time, but improvements are always welcome!
|
|||
operations that would not normally be undertaken while a real-time
|
||||
workload is running.
|
||||
|
||||
In particular, if you find yourself invoking one of the expedited
|
||||
primitives repeatedly in a loop, please do everyone a favor:
|
||||
Restructure your code so that it batches the updates, allowing
|
||||
a single non-expedited primitive to cover the entire batch.
|
||||
This will very likely be faster than the loop containing the
|
||||
expedited primitive, and will be much much easier on the rest
|
||||
of the system, especially to real-time workloads running on
|
||||
the rest of the system.
|
||||
|
||||
In addition, it is illegal to call the expedited forms from
|
||||
a CPU-hotplug notifier, or while holding a lock that is acquired
|
||||
by a CPU-hotplug notifier. Failing to observe this restriction
|
||||
will result in deadlock.
|
||||
|
||||
7. If the updater uses call_rcu() or synchronize_rcu(), then the
|
||||
corresponding readers must use rcu_read_lock() and
|
||||
rcu_read_unlock(). If the updater uses call_rcu_bh() or
|
||||
|
|
|
|||
|
|
@ -12,14 +12,38 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
This kernel configuration parameter defines the period of time
|
||||
that RCU will wait from the beginning of a grace period until it
|
||||
issues an RCU CPU stall warning. This time period is normally
|
||||
ten seconds.
|
||||
sixty seconds.
|
||||
|
||||
RCU_SECONDS_TILL_STALL_RECHECK
|
||||
This configuration parameter may be changed at runtime via the
|
||||
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
|
||||
this parameter is checked only at the beginning of a cycle.
|
||||
So if you are 30 seconds into a 70-second stall, setting this
|
||||
sysfs parameter to (say) five will shorten the timeout for the
|
||||
-next- stall, or the following warning for the current stall
|
||||
(assuming the stall lasts long enough). It will not affect the
|
||||
timing of the next warning for the current stall.
|
||||
|
||||
This macro defines the period of time that RCU will wait after
|
||||
issuing a stall warning until it issues another stall warning
|
||||
for the same stall. This time period is normally set to three
|
||||
times the check interval plus thirty seconds.
|
||||
Stall-warning messages may be enabled and disabled completely via
|
||||
/sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_VERBOSE
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
also dump the stacks of any tasks that are blocking the current
|
||||
RCU-preempt grace period.
|
||||
|
||||
RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
print out additional per-CPU diagnostic information, including
|
||||
information on scheduling-clock ticks and RCU's idle-CPU tracking.
|
||||
|
||||
RCU_STALL_DELAY_DELTA
|
||||
|
||||
Although the lockdep facility is extremely useful, it does add
|
||||
some overhead. Therefore, under CONFIG_PROVE_RCU, the
|
||||
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
|
||||
giving an RCU CPU stall warning message.
|
||||
|
||||
RCU_STALL_RAT_DELAY
|
||||
|
||||
|
|
@ -64,6 +88,54 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffi
|
|||
|
||||
This is rare, but does happen from time to time in real life.
|
||||
|
||||
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
|
||||
(t=65000 jiffies)
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||
printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
|
||||
(t=65000 jiffies)
|
||||
|
||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||
than 64,000 scheduling-clock interrupts during the current stalled
|
||||
grace period. If the CPU was not yet aware of the current grace
|
||||
period (for example, if it was offline), then this part of the message
|
||||
indicates how many grace periods behind the CPU is.
|
||||
|
||||
The "idle=" portion of the message prints the dyntick-idle state.
|
||||
The hex number before the first "/" is the low-order 12 bits of the
|
||||
dynticks counter, which will have an even-numbered value if the CPU is
|
||||
in dyntick-idle mode and an odd-numbered value otherwise. The hex
|
||||
number between the two "/"s is the value of the nesting, which will
|
||||
be a small positive number if in the idle loop and a very large positive
|
||||
number (as shown above) otherwise.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
|
||||
CPU is not in the process of trying to force itself into dyntick-idle
|
||||
state, the "." indicates that the CPU has not given up forcing RCU
|
||||
into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
|
||||
indicates that the CPU has not recented forced RCU into dyntick-idle
|
||||
mode (it would otherwise indicate the number of microseconds remaining
|
||||
in this forced state).
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
||||
If a stall lasts long enough, multiple stall-warning messages will be
|
||||
printed for it. The second and subsequent messages are printed at
|
||||
longer intervals, so that the time between (say) the first and second
|
||||
message will be about three times the interval between the beginning
|
||||
of the stall and the first message.
|
||||
|
||||
|
||||
What Causes RCU CPU Stall Warnings?
|
||||
|
||||
So your kernel printed an RCU CPU stall warning. The next question is
|
||||
"What caused it?" The following problems can result in RCU CPU stall
|
||||
warnings:
|
||||
|
|
@ -128,4 +200,5 @@ is occurring, which will usually be in the function nearest the top of
|
|||
that portion of the stack which remains the same from trace to trace.
|
||||
If you can reliably trigger the stall, ftrace can be quite helpful.
|
||||
|
||||
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.
|
||||
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
|
||||
and with RCU's event tracing.
|
||||
|
|
|
|||
|
|
@ -69,6 +69,13 @@ onoff_interval
|
|||
CPU-hotplug operations regardless of what value is
|
||||
specified for onoff_interval.
|
||||
|
||||
onoff_holdoff The number of seconds to wait until starting CPU-hotplug
|
||||
operations. This would normally only be used when
|
||||
rcutorture was built into the kernel and started
|
||||
automatically at boot time, in which case it is useful
|
||||
in order to avoid confusing boot-time code with CPUs
|
||||
coming and going.
|
||||
|
||||
shuffle_interval
|
||||
The number of seconds to keep the test threads affinitied
|
||||
to a particular subset of the CPUs, defaults to 3 seconds.
|
||||
|
|
@ -79,6 +86,24 @@ shutdown_secs The number of seconds to run the test before terminating
|
|||
zero, which disables test termination and system shutdown.
|
||||
This capability is useful for automated testing.
|
||||
|
||||
stall_cpu The number of seconds that a CPU should be stalled while
|
||||
within both an rcu_read_lock() and a preempt_disable().
|
||||
This stall happens only once per rcutorture run.
|
||||
If you need multiple stalls, use modprobe and rmmod to
|
||||
repeatedly run rcutorture. The default for stall_cpu
|
||||
is zero, which prevents rcutorture from stalling a CPU.
|
||||
|
||||
Note that attempts to rmmod rcutorture while the stall
|
||||
is ongoing will hang, so be careful what value you
|
||||
choose for this module parameter! In addition, too-large
|
||||
values for stall_cpu might well induce failures and
|
||||
warnings in other parts of the kernel. You have been
|
||||
warned!
|
||||
|
||||
stall_cpu_holdoff
|
||||
The number of seconds to wait after rcutorture starts
|
||||
before stalling a CPU. Defaults to 10 seconds.
|
||||
|
||||
stat_interval The number of seconds between output of torture
|
||||
statistics (via printk()). Regardless of the interval,
|
||||
statistics are printed when the module is unloaded.
|
||||
|
|
@ -271,11 +296,13 @@ The following script may be used to torture RCU:
|
|||
#!/bin/sh
|
||||
|
||||
modprobe rcutorture
|
||||
sleep 100
|
||||
sleep 3600
|
||||
rmmod rcutorture
|
||||
dmesg | grep torture:
|
||||
|
||||
The output can be manually inspected for the error flag of "!!!".
|
||||
One could of course create a more elaborate script that automatically
|
||||
checked for such errors. The "rmmod" command forces a "SUCCESS" or
|
||||
"FAILURE" indication to be printk()ed.
|
||||
checked for such errors. The "rmmod" command forces a "SUCCESS",
|
||||
"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first
|
||||
two are self-explanatory, while the last indicates that while there
|
||||
were no RCU failures, CPU-hotplug problems were detected.
|
||||
|
|
|
|||
|
|
@ -33,23 +33,23 @@ rcu/rcuboost:
|
|||
The output of "cat rcu/rcudata" looks as follows:
|
||||
|
||||
rcu_sched:
|
||||
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
|
||||
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
|
||||
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
|
||||
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
|
||||
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
|
||||
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
|
||||
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
|
||||
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
|
||||
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
|
||||
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
|
||||
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
|
||||
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
|
||||
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
|
||||
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
|
||||
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
|
||||
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
|
||||
rcu_bh:
|
||||
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
|
||||
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
|
||||
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
|
||||
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
|
||||
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
|
||||
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
|
||||
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
|
||||
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
|
||||
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
|
||||
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
|
||||
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
|
||||
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
|
||||
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
|
||||
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
|
||||
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
|
||||
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
|
||||
|
||||
The first section lists the rcu_data structures for rcu_sched, the second
|
||||
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
|
||||
|
|
@ -119,10 +119,6 @@ o "of" is the number of times that some other CPU has forced a
|
|||
CPU is offline when it is really alive and kicking) is a fatal
|
||||
error, so it makes sense to err conservatively.
|
||||
|
||||
o "ri" is the number of times that RCU has seen fit to send a
|
||||
reschedule IPI to this CPU in order to get it to report a
|
||||
quiescent state.
|
||||
|
||||
o "ql" is the number of RCU callbacks currently residing on
|
||||
this CPU. This is the total number of callbacks, regardless
|
||||
of what state they are in (new, waiting for grace period to
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ inline (either in the code emitted directly by the compiler, or part of
|
|||
the implementation of a library call) when optimizing for a recent enough
|
||||
processor that has the necessary native support, but only if resulting
|
||||
binaries are already to be incompatible with earlier ARM processors due to
|
||||
useage of similar native instructions for other things. In other words
|
||||
usage of similar native instructions for other things. In other words
|
||||
don't make binaries unable to run on earlier processors just for the sake
|
||||
of not using these kernel helpers if your compiled code is not going to
|
||||
use new instructions for other purpose.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
Kernel driver lp855x
|
||||
====================
|
||||
|
||||
Backlight driver for LP855x ICs
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
|
||||
|
||||
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
* Brightness control
|
||||
|
||||
Brightness can be controlled by the pwm input or the i2c command.
|
||||
The lp855x driver supports both cases.
|
||||
|
||||
* Device attributes
|
||||
|
||||
1) bl_ctl_mode
|
||||
Backlight control mode.
|
||||
Value : pwm based or register based
|
||||
|
||||
2) chip_id
|
||||
The lp855x chip id.
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556
|
||||
|
||||
Platform data for lp855x
|
||||
------------------------
|
||||
|
||||
For supporting platform specific data, the lp855x platform data can be used.
|
||||
|
||||
* name : Backlight driver name. If it is not defined, default name is set.
|
||||
* mode : Brightness control mode. PWM or register based.
|
||||
* device_control : Value of DEVICE CONTROL register.
|
||||
* initial_brightness : Initial value of backlight brightness.
|
||||
* pwm_data : Platform specific pwm generation functions.
|
||||
Only valid when brightness is pwm input mode.
|
||||
Functions should be implemented by PWM driver.
|
||||
- pwm_set_intensity() : set duty of PWM
|
||||
- pwm_get_intensity() : get current duty of PWM
|
||||
* load_new_rom_data :
|
||||
0 : use default configuration data
|
||||
1 : update values of eeprom or eprom registers on loading driver
|
||||
* size_program : Total size of lp855x_rom_data.
|
||||
* rom_data : List of new eeprom/eprom registers.
|
||||
|
||||
example 1) lp8552 platform data : i2c register mode with new eeprom data
|
||||
|
||||
#define EEPROM_A5_ADDR 0xA5
|
||||
#define EEPROM_A5_VAL 0x4f /* EN_VSYNC=0 */
|
||||
|
||||
static struct lp855x_rom_data lp8552_eeprom_arr[] = {
|
||||
{EEPROM_A5_ADDR, EEPROM_A5_VAL},
|
||||
};
|
||||
|
||||
static struct lp855x_platform_data lp8552_pdata = {
|
||||
.name = "lcd-bl",
|
||||
.mode = REGISTER_BASED,
|
||||
.device_control = I2C_CONFIG(LP8552),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.load_new_rom_data = 1,
|
||||
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
|
||||
.rom_data = lp8552_eeprom_arr,
|
||||
};
|
||||
|
||||
example 2) lp8556 platform data : pwm input mode with default rom data
|
||||
|
||||
static struct lp855x_platform_data lp8556_pdata = {
|
||||
.mode = PWM_BASED,
|
||||
.device_control = PWM_CONFIG(LP8556),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.pwm_data = {
|
||||
.pwm_set_intensity = platform_pwm_set_intensity,
|
||||
.pwm_get_intensity = platform_pwm_get_intensity,
|
||||
},
|
||||
};
|
||||
|
|
@ -94,11 +94,11 @@ Throttling/Upper Limit policy
|
|||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently none of the IO control policy supports hierarhical groups. But
|
||||
cgroup interface does allow creation of hierarhical cgroups and internally
|
||||
- Currently none of the IO control policy supports hierarchical groups. But
|
||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
||||
IO policies treat them as flat hierarchy.
|
||||
|
||||
So this patch will allow creation of cgroup hierarhcy but at the backend
|
||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
||||
everything will be treated as flat. So if somebody created a hierarchy like
|
||||
as follows.
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ Proportional weight policy files
|
|||
- blkio.idle_time
|
||||
- Debugging aid only enabled if CONFIG_DEBUG_BLK_CGROUP=y.
|
||||
This is the amount of time spent by the IO scheduler idling for a
|
||||
given cgroup in anticipation of a better request than the exising ones
|
||||
given cgroup in anticipation of a better request than the existing ones
|
||||
from other queues/cgroups. This is in nanoseconds. If this is read
|
||||
when the cgroup is in an idling state, the stat will only report the
|
||||
idle_time accumulated till the last idle period and will not include
|
||||
|
|
@ -283,34 +283,34 @@ Throttling/Upper limit policy files
|
|||
-----------------------------------
|
||||
- blkio.throttle.read_bps_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device
|
||||
|
||||
- blkio.throttle.write_bps_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device
|
||||
|
||||
- blkio.throttle.read_iops_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in IO per second. Rules are per deivce. Following is
|
||||
specified in IO per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device
|
||||
|
||||
- blkio.throttle.write_iops_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in io per second. Rules are per deivce. Following is
|
||||
specified in io per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device
|
||||
|
||||
Note: If both BW and IOPS rules are specified for a device, then IO is
|
||||
subjectd to both the constraints.
|
||||
subjected to both the constraints.
|
||||
|
||||
- blkio.throttle.io_serviced
|
||||
- Number of IOs (bio) completed to/from the disk by the group (as
|
||||
|
|
|
|||
|
|
@ -558,8 +558,7 @@ Each subsystem may export the following methods. The only mandatory
|
|||
methods are create/destroy. Any others that are null are presumed to
|
||||
be successful no-ops.
|
||||
|
||||
struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
|
||||
struct cgroup *cgrp)
|
||||
struct cgroup_subsys_state *create(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called to create a subsystem state object for a cgroup. The
|
||||
|
|
@ -574,7 +573,7 @@ identified by the passed cgroup object having a NULL parent (since
|
|||
it's the root of the hierarchy) and may be an appropriate place for
|
||||
initialization code.
|
||||
|
||||
void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
void destroy(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
The cgroup system is about to destroy the passed cgroup; the subsystem
|
||||
|
|
@ -585,7 +584,7 @@ cgroup->parent is still valid. (Note - can also be called for a
|
|||
newly-created cgroup if an error occurs after this subsystem's
|
||||
create() method has been called for the new cgroup).
|
||||
|
||||
int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
|
||||
int pre_destroy(struct cgroup *cgrp);
|
||||
|
||||
Called before checking the reference count on each subsystem. This may
|
||||
be useful for subsystems which have some extra references even if
|
||||
|
|
@ -593,8 +592,7 @@ there are not tasks in the cgroup. If pre_destroy() returns error code,
|
|||
rmdir() will fail with it. From this behavior, pre_destroy() can be
|
||||
called multiple times against a cgroup.
|
||||
|
||||
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving one or more tasks into a cgroup; if the
|
||||
|
|
@ -615,8 +613,7 @@ fork. If this method returns 0 (success) then this should remain valid
|
|||
while the caller holds cgroup_mutex and it is ensured that either
|
||||
attach() or cancel_attach() will be called in future.
|
||||
|
||||
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called when a task attach operation has failed after can_attach() has succeeded.
|
||||
|
|
@ -625,23 +622,22 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
|
|||
This will be called only about subsystems whose can_attach() operation have
|
||||
succeeded. The parameters are identical to can_attach().
|
||||
|
||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after the task has been attached to the cgroup, to allow any
|
||||
post-attachment activity that requires memory allocations or blocking.
|
||||
The parameters are identical to can_attach().
|
||||
|
||||
void fork(struct cgroup_subsy *ss, struct task_struct *task)
|
||||
void fork(struct task_struct *task)
|
||||
|
||||
Called when a task is forked into a cgroup.
|
||||
|
||||
void exit(struct cgroup_subsys *ss, struct task_struct *task)
|
||||
void exit(struct task_struct *task)
|
||||
|
||||
Called during task exit.
|
||||
|
||||
int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
int populate(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after creation of a cgroup to allow a subsystem to populate
|
||||
|
|
@ -651,7 +647,7 @@ include/linux/cgroup.h for details). Note that although this
|
|||
method can return an error code, the error code is currently not
|
||||
always handled well.
|
||||
|
||||
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
void post_clone(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called during cgroup_create() to do any parameter
|
||||
|
|
@ -659,7 +655,7 @@ initialization which might be required before a task could attach. For
|
|||
example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
up.
|
||||
|
||||
void bind(struct cgroup_subsys *ss, struct cgroup *root)
|
||||
void bind(struct cgroup *root)
|
||||
(cgroup_mutex and ss->hierarchy_mutex held by caller)
|
||||
|
||||
Called when a cgroup subsystem is rebound to a different hierarchy
|
||||
|
|
|
|||
|
|
@ -0,0 +1,182 @@
|
|||
A brief CRC tutorial.
|
||||
|
||||
A CRC is a long-division remainder. You add the CRC to the message,
|
||||
and the whole thing (message+CRC) is a multiple of the given
|
||||
CRC polynomial. To check the CRC, you can either check that the
|
||||
CRC matches the recomputed value, *or* you can check that the
|
||||
remainder computed on the message+CRC is 0. This latter approach
|
||||
is used by a lot of hardware implementations, and is why so many
|
||||
protocols put the end-of-frame flag after the CRC.
|
||||
|
||||
It's actually the same long division you learned in school, except that
|
||||
- We're working in binary, so the digits are only 0 and 1, and
|
||||
- When dividing polynomials, there are no carries. Rather than add and
|
||||
subtract, we just xor. Thus, we tend to get a bit sloppy about
|
||||
the difference between adding and subtracting.
|
||||
|
||||
Like all division, the remainder is always smaller than the divisor.
|
||||
To produce a 32-bit CRC, the divisor is actually a 33-bit CRC polynomial.
|
||||
Since it's 33 bits long, bit 32 is always going to be set, so usually the
|
||||
CRC is written in hex with the most significant bit omitted. (If you're
|
||||
familiar with the IEEE 754 floating-point format, it's the same idea.)
|
||||
|
||||
Note that a CRC is computed over a string of *bits*, so you have
|
||||
to decide on the endianness of the bits within each byte. To get
|
||||
the best error-detecting properties, this should correspond to the
|
||||
order they're actually sent. For example, standard RS-232 serial is
|
||||
little-endian; the most significant bit (sometimes used for parity)
|
||||
is sent last. And when appending a CRC word to a message, you should
|
||||
do it in the right order, matching the endianness.
|
||||
|
||||
Just like with ordinary division, you proceed one digit (bit) at a time.
|
||||
Each step of the division you take one more digit (bit) of the dividend
|
||||
and append it to the current remainder. Then you figure out the
|
||||
appropriate multiple of the divisor to subtract to being the remainder
|
||||
back into range. In binary, this is easy - it has to be either 0 or 1,
|
||||
and to make the XOR cancel, it's just a copy of bit 32 of the remainder.
|
||||
|
||||
When computing a CRC, we don't care about the quotient, so we can
|
||||
throw the quotient bit away, but subtract the appropriate multiple of
|
||||
the polynomial from the remainder and we're back to where we started,
|
||||
ready to process the next bit.
|
||||
|
||||
A big-endian CRC written this way would be coded like:
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
multiple = remainder & 0x80000000 ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1 | next_input_bit()) ^ multiple;
|
||||
}
|
||||
|
||||
Notice how, to get at bit 32 of the shifted remainder, we look
|
||||
at bit 31 of the remainder *before* shifting it.
|
||||
|
||||
But also notice how the next_input_bit() bits we're shifting into
|
||||
the remainder don't actually affect any decision-making until
|
||||
32 bits later. Thus, the first 32 cycles of this are pretty boring.
|
||||
Also, to add the CRC to a message, we need a 32-bit-long hole for it at
|
||||
the end, so we have to add 32 extra cycles shifting in zeros at the
|
||||
end of every message,
|
||||
|
||||
These details lead to a standard trick: rearrange merging in the
|
||||
next_input_bit() until the moment it's needed. Then the first 32 cycles
|
||||
can be precomputed, and merging in the final 32 zero bits to make room
|
||||
for the CRC can be skipped entirely. This changes the code to:
|
||||
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
remainder ^= next_input_bit() << 31;
|
||||
multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1) ^ multiple;
|
||||
}
|
||||
|
||||
With this optimization, the little-endian code is particularly simple:
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
remainder ^= next_input_bit();
|
||||
multiple = (remainder & 1) ? CRCPOLY : 0;
|
||||
remainder = (remainder >> 1) ^ multiple;
|
||||
}
|
||||
|
||||
The most significant coefficient of the remainder polynomial is stored
|
||||
in the least significant bit of the binary "remainder" variable.
|
||||
The other details of endianness have been hidden in CRCPOLY (which must
|
||||
be bit-reversed) and next_input_bit().
|
||||
|
||||
As long as next_input_bit is returning the bits in a sensible order, we don't
|
||||
*have* to wait until the last possible moment to merge in additional bits.
|
||||
We can do it 8 bits at a time rather than 1 bit at a time:
|
||||
for (i = 0; i < input_bytes; i++) {
|
||||
remainder ^= next_input_byte() << 24;
|
||||
for (j = 0; j < 8; j++) {
|
||||
multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1) ^ multiple;
|
||||
}
|
||||
}
|
||||
|
||||
Or in little-endian:
|
||||
for (i = 0; i < input_bytes; i++) {
|
||||
remainder ^= next_input_byte();
|
||||
for (j = 0; j < 8; j++) {
|
||||
multiple = (remainder & 1) ? CRCPOLY : 0;
|
||||
remainder = (remainder >> 1) ^ multiple;
|
||||
}
|
||||
}
|
||||
|
||||
If the input is a multiple of 32 bits, you can even XOR in a 32-bit
|
||||
word at a time and increase the inner loop count to 32.
|
||||
|
||||
You can also mix and match the two loop styles, for example doing the
|
||||
bulk of a message byte-at-a-time and adding bit-at-a-time processing
|
||||
for any fractional bytes at the end.
|
||||
|
||||
To reduce the number of conditional branches, software commonly uses
|
||||
the byte-at-a-time table method, popularized by Dilip V. Sarwate,
|
||||
"Computation of Cyclic Redundancy Checks via Table Look-Up", Comm. ACM
|
||||
v.31 no.8 (August 1998) p. 1008-1013.
|
||||
|
||||
Here, rather than just shifting one bit of the remainder to decide
|
||||
in the correct multiple to subtract, we can shift a byte at a time.
|
||||
This produces a 40-bit (rather than a 33-bit) intermediate remainder,
|
||||
and the correct multiple of the polynomial to subtract is found using
|
||||
a 256-entry lookup table indexed by the high 8 bits.
|
||||
|
||||
(The table entries are simply the CRC-32 of the given one-byte messages.)
|
||||
|
||||
When space is more constrained, smaller tables can be used, e.g. two
|
||||
4-bit shifts followed by a lookup in a 16-entry table.
|
||||
|
||||
It is not practical to process much more than 8 bits at a time using this
|
||||
technique, because tables larger than 256 entries use too much memory and,
|
||||
more importantly, too much of the L1 cache.
|
||||
|
||||
To get higher software performance, a "slicing" technique can be used.
|
||||
See "High Octane CRC Generation with the Intel Slicing-by-8 Algorithm",
|
||||
ftp://download.intel.com/technology/comms/perfnet/download/slicing-by-8.pdf
|
||||
|
||||
This does not change the number of table lookups, but does increase
|
||||
the parallelism. With the classic Sarwate algorithm, each table lookup
|
||||
must be completed before the index of the next can be computed.
|
||||
|
||||
A "slicing by 2" technique would shift the remainder 16 bits at a time,
|
||||
producing a 48-bit intermediate remainder. Rather than doing a single
|
||||
lookup in a 65536-entry table, the two high bytes are looked up in
|
||||
two different 256-entry tables. Each contains the remainder required
|
||||
to cancel out the corresponding byte. The tables are different because the
|
||||
polynomials to cancel are different. One has non-zero coefficients from
|
||||
x^32 to x^39, while the other goes from x^40 to x^47.
|
||||
|
||||
Since modern processors can handle many parallel memory operations, this
|
||||
takes barely longer than a single table look-up and thus performs almost
|
||||
twice as fast as the basic Sarwate algorithm.
|
||||
|
||||
This can be extended to "slicing by 4" using 4 256-entry tables.
|
||||
Each step, 32 bits of data is fetched, XORed with the CRC, and the result
|
||||
broken into bytes and looked up in the tables. Because the 32-bit shift
|
||||
leaves the low-order bits of the intermediate remainder zero, the
|
||||
final CRC is simply the XOR of the 4 table look-ups.
|
||||
|
||||
But this still enforces sequential execution: a second group of table
|
||||
look-ups cannot begin until the previous groups 4 table look-ups have all
|
||||
been completed. Thus, the processor's load/store unit is sometimes idle.
|
||||
|
||||
To make maximum use of the processor, "slicing by 8" performs 8 look-ups
|
||||
in parallel. Each step, the 32-bit CRC is shifted 64 bits and XORed
|
||||
with 64 bits of input data. What is important to note is that 4 of
|
||||
those 8 bytes are simply copies of the input data; they do not depend
|
||||
on the previous CRC at all. Thus, those 4 table look-ups may commence
|
||||
immediately, without waiting for the previous loop iteration.
|
||||
|
||||
By always having 4 loads in flight, a modern superscalar processor can
|
||||
be kept busy and make full use of its L1 cache.
|
||||
|
||||
Two more details about CRC implementation in the real world:
|
||||
|
||||
Normally, appending zero bits to a message which is already a multiple
|
||||
of a polynomial produces a larger multiple of that polynomial. Thus,
|
||||
a basic CRC will not detect appended zero bits (or bytes). To enable
|
||||
a CRC to detect this condition, it's common to invert the CRC before
|
||||
appending it. This makes the remainder of the message+crc come out not
|
||||
as zero, but some fixed non-zero value. (The CRC of the inversion
|
||||
pattern, 0xffffffff.)
|
||||
|
||||
The same problem applies to zero bits prepended to the message, and a
|
||||
similar solution is used. Instead of starting the CRC computation with
|
||||
a remainder of 0, an initial remainder of all ones is used. As long as
|
||||
you start the same way on decoding, it doesn't make a difference.
|
||||
|
|
@ -28,7 +28,7 @@ The target is named "raid" and it accepts the following parameters:
|
|||
raid6_nc RAID6 N continue
|
||||
- rotating parity N (right-to-left) with data continuation
|
||||
|
||||
Refererence: Chapter 4 of
|
||||
Reference: Chapter 4 of
|
||||
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
|
||||
<#raid_params>: The number of parameters that follow.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Introduction
|
|||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
different targets were rolling their own data structures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
This document descibes a collection of device-mapper targets that
|
||||
This document describes a collection of device-mapper targets that
|
||||
between them implement thin-provisioning and snapshots.
|
||||
|
||||
The main highlight of this implementation, compared to the previous
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
* Samsung Exynos Power Domains
|
||||
|
||||
Exynos processors include support for multiple power domains which are used
|
||||
to gate power to one or more peripherals on the processor.
|
||||
|
||||
Required Properties:
|
||||
- compatiable: should be one of the following.
|
||||
* samsung,exynos4210-pd - for exynos4210 type power domain.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
Optional Properties:
|
||||
- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
|
||||
state during boot and remains to be turned-off until explicitly turned-on.
|
||||
|
||||
Example:
|
||||
|
||||
lcd0: power-domain-lcd0 {
|
||||
compatible = "samsung,exynos4210-pd";
|
||||
reg = <0x10023C00 0x10>;
|
||||
};
|
||||
|
|
@ -5,7 +5,7 @@ IPs present in the SoC.
|
|||
On top of that an omap_device is created to extend the platform_device
|
||||
capabilities and to allow binding with one or several hwmods.
|
||||
The hwmods will contain all the information to build the device:
|
||||
adresse range, irq lines, dma lines, interconnect, PRCM register,
|
||||
address range, irq lines, dma lines, interconnect, PRCM register,
|
||||
clock domain, input clocks.
|
||||
For the moment just point to the existing hwmod, the next step will be
|
||||
to move data from hwmod to device-tree representation.
|
||||
|
|
@ -41,3 +41,9 @@ Boards:
|
|||
|
||||
- OMAP4 PandaBoard : Low cost community board
|
||||
compatible = "ti,omap4-panda", "ti,omap4430"
|
||||
|
||||
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
|
||||
compatible = "ti,omap3-evm", "ti,omap3"
|
||||
|
||||
- AM335X EVM : Software Developement Board for AM335x
|
||||
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
prima2 "cb" evalutation board
|
||||
prima2 "cb" evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "sirf,prima2-cb", "sirf,prima2";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
A simple common binding for matrix-connected key boards. Currently targeted at
|
||||
defining the keys in the scope of linux key codes since that is a stable and
|
||||
standardized interface at this time.
|
||||
|
||||
Required properties:
|
||||
- linux,keymap: an array of packed 1-cell entries containing the equivalent
|
||||
of row, column and linux key-code. The 32-bit big endian cell is packed
|
||||
as:
|
||||
row << 24 | column << 16 | key-code
|
||||
|
||||
Optional properties:
|
||||
Some users of this binding might choose to specify secondary keymaps for
|
||||
cases where there is a modifier key such as a Fn key. Proposed names
|
||||
for said properties are "linux,fn-keymap" or with another descriptive
|
||||
word for the modifier other from "Fn".
|
||||
|
||||
Example:
|
||||
linux,keymap = < 0x00030012
|
||||
0x0102003a >;
|
||||
|
|
@ -3,16 +3,21 @@
|
|||
Required properties:
|
||||
- compatible: "nvidia,tegra20-kbc"
|
||||
|
||||
Optional properties:
|
||||
- debounce-delay: delay in milliseconds per row scan for debouncing
|
||||
- repeat-delay: delay in milliseconds before repeat starts
|
||||
- ghost-filter: enable ghost filtering for this device
|
||||
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
Optional properties, in addition to those specified by the shared
|
||||
matrix-keyboard bindings:
|
||||
|
||||
- linux,fn-keymap: a second keymap, same specification as the
|
||||
matrix-keyboard-controller spec but to be used when the KEY_FN modifier
|
||||
key is pressed.
|
||||
- nvidia,debounce-delay-ms: delay in milliseconds per row scan for debouncing
|
||||
- nvidia,repeat-delay-ms: delay in milliseconds before repeat starts
|
||||
- nvidia,ghost-filter: enable ghost filtering for this device
|
||||
- nvidia,wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
|
||||
Example:
|
||||
|
||||
keyboard: keyboard {
|
||||
compatible = "nvidia,tegra20-kbc";
|
||||
reg = <0x7000e200 0x100>;
|
||||
ghost-filter;
|
||||
nvidia,ghost-filter;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "st,spear600-gmac"
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupts: Should contain the STMMAC interrupts
|
||||
- interrupt-names: Should contain the interrupt names "macirq"
|
||||
"eth_wake_irq" if this interrupt is supported in the "interrupts"
|
||||
property
|
||||
- phy-mode: String, operation mode of the PHY interface.
|
||||
Supported values are: "mii", "rmii", "gmii", "rgmii".
|
||||
|
||||
Optional properties:
|
||||
- mac-address: 6 bytes, mac address
|
||||
|
||||
Examples:
|
||||
|
||||
gmac0: ethernet@e0800000 {
|
||||
compatible = "st,spear600-gmac";
|
||||
reg = <0xe0800000 0x8000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <24 23>;
|
||||
interrupt-names = "macirq", "eth_wake_irq";
|
||||
mac-address = [000000000000]; /* Filled in by U-Boot */
|
||||
phy-mode = "gmii";
|
||||
};
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
* FSL MPIC Message Registers
|
||||
|
||||
This binding specifies what properties must be available in the device tree
|
||||
representation of the message register blocks found in some FSL MPIC
|
||||
implementations.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Specifies the compatibility list for the message register
|
||||
block. The type shall be <string-list> and the value shall be of the form
|
||||
"fsl,mpic-v<version>-msgr", where <version> is the version number of
|
||||
the MPIC containing the message registers.
|
||||
|
||||
- reg: Specifies the base physical address(s) and size(s) of the
|
||||
message register block's addressable register space. The type shall be
|
||||
<prop-encoded-array>.
|
||||
|
||||
- interrupts: Specifies a list of interrupt-specifiers which are available
|
||||
for receiving interrupts. Interrupt-specifier consists of two cells: first
|
||||
cell is interrupt-number and second cell is level-sense. The type shall be
|
||||
<prop-encoded-array>.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- mpic-msgr-receive-mask: Specifies what registers in the containing block
|
||||
are allowed to receive interrupts. The value is a bit mask where a set
|
||||
bit at bit 'n' indicates that message register 'n' can receive interrupts.
|
||||
Note that "bit 'n'" is numbered from LSB for PPC hardware. The type shall
|
||||
be <u32>. If not present, then all of the message registers in the block
|
||||
are available.
|
||||
|
||||
Aliases:
|
||||
|
||||
An alias should be created for every message register block. They are not
|
||||
required, though. However, a particular implementation of this binding
|
||||
may require aliases to be present. Aliases are of the form
|
||||
'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
|
||||
Numbers shall start at 0.
|
||||
|
||||
Example:
|
||||
|
||||
aliases {
|
||||
mpic-msgr-block0 = &mpic_msgr_block0;
|
||||
mpic-msgr-block1 = &mpic_msgr_block1;
|
||||
};
|
||||
|
||||
mpic_msgr_block0: mpic-msgr-block@41400 {
|
||||
compatible = "fsl,mpic-v3.1-msgr";
|
||||
reg = <0x41400 0x200>;
|
||||
// Message registers 0 and 2 in this block can receive interrupts on
|
||||
// sources 0xb0 and 0xb2, respectively.
|
||||
interrupts = <0xb0 2 0xb2 2>;
|
||||
mpic-msgr-receive-mask = <0x5>;
|
||||
};
|
||||
|
||||
mpic_msgr_block1: mpic-msgr-block@42400 {
|
||||
compatible = "fsl,mpic-v3.1-msgr";
|
||||
reg = <0x42400 0x200>;
|
||||
// Message registers 0 and 2 in this block can receive interrupts on
|
||||
// sources 0xb4 and 0xb6, respectively.
|
||||
interrupts = <0xb4 2 0xb6 2>;
|
||||
mpic-msgr-receive-mask = <0x5>;
|
||||
};
|
||||
|
|
@ -56,7 +56,27 @@ PROPERTIES
|
|||
to the client. The presence of this property also mandates
|
||||
that any initialization related to interrupt sources shall
|
||||
be limited to sources explicitly referenced in the device tree.
|
||||
|
||||
|
||||
- big-endian
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
If present the MPIC will be assumed to be big-endian. Some
|
||||
device-trees omit this property on MPIC nodes even when the MPIC is
|
||||
in fact big-endian, so certain boards override this property.
|
||||
|
||||
- single-cpu-affinity
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
If present the MPIC will be assumed to only be able to route
|
||||
non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC).
|
||||
|
||||
- last-interrupt-source
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Some MPICs do not correctly report the number of hardware sources
|
||||
in the global feature registers. If specified, this field will
|
||||
override the value read from MPIC_GREG_FEATURE_LAST_SRC.
|
||||
|
||||
INTERRUPT SPECIFIER DEFINITION
|
||||
|
||||
Interrupt specifiers consists of 4 cells encoded as
|
||||
|
|
|
|||
|
|
@ -6,8 +6,10 @@ Required properties:
|
|||
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
|
||||
the parent type.
|
||||
|
||||
- reg : should contain the address and the length of the shared message
|
||||
interrupt register set.
|
||||
- reg : It may contain one or two regions. The first region should contain
|
||||
the address and the length of the shared message interrupt register set.
|
||||
The second region should contain the address of aliased MSIIR register for
|
||||
platforms that have such an alias.
|
||||
|
||||
- msi-available-ranges: use <start count> style section to define which
|
||||
msi interrupt can be used in the 256 msi interrupts. This property is
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
TWL family of regulators
|
||||
|
||||
Required properties:
|
||||
For twl6030 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl6030-vaux1" for VAUX1 LDO
|
||||
- "ti,twl6030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl6030-vaux3" for VAUX3 LDO
|
||||
- "ti,twl6030-vmmc" for VMMC LDO
|
||||
- "ti,twl6030-vpp" for VPP LDO
|
||||
- "ti,twl6030-vusim" for VUSIM LDO
|
||||
- "ti,twl6030-vana" for VANA LDO
|
||||
- "ti,twl6030-vcxio" for VCXIO LDO
|
||||
- "ti,twl6030-vdac" for VDAC LDO
|
||||
- "ti,twl6030-vusb" for VUSB LDO
|
||||
- "ti,twl6030-v1v8" for V1V8 LDO
|
||||
- "ti,twl6030-v2v1" for V2V1 LDO
|
||||
- "ti,twl6030-clk32kg" for CLK32KG RESOURCE
|
||||
- "ti,twl6030-vdd1" for VDD1 SMPS
|
||||
- "ti,twl6030-vdd2" for VDD2 SMPS
|
||||
- "ti,twl6030-vdd3" for VDD3 SMPS
|
||||
For twl6025 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl6025-ldo1" for LDO1 LDO
|
||||
- "ti,twl6025-ldo2" for LDO2 LDO
|
||||
- "ti,twl6025-ldo3" for LDO3 LDO
|
||||
- "ti,twl6025-ldo4" for LDO4 LDO
|
||||
- "ti,twl6025-ldo5" for LDO5 LDO
|
||||
- "ti,twl6025-ldo6" for LDO6 LDO
|
||||
- "ti,twl6025-ldo7" for LDO7 LDO
|
||||
- "ti,twl6025-ldoln" for LDOLN LDO
|
||||
- "ti,twl6025-ldousb" for LDOUSB LDO
|
||||
- "ti,twl6025-smps3" for SMPS3 SMPS
|
||||
- "ti,twl6025-smps4" for SMPS4 SMPS
|
||||
- "ti,twl6025-vio" for VIO SMPS
|
||||
For twl4030 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl4030-vaux1" for VAUX1 LDO
|
||||
- "ti,twl4030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl5030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl4030-vaux3" for VAUX3 LDO
|
||||
- "ti,twl4030-vaux4" for VAUX4 LDO
|
||||
- "ti,twl4030-vmmc1" for VMMC1 LDO
|
||||
- "ti,twl4030-vmmc2" for VMMC2 LDO
|
||||
- "ti,twl4030-vpll1" for VPLL1 LDO
|
||||
- "ti,twl4030-vpll2" for VPLL2 LDO
|
||||
- "ti,twl4030-vsim" for VSIM LDO
|
||||
- "ti,twl4030-vdac" for VDAC LDO
|
||||
- "ti,twl4030-vintana2" for VINTANA2 LDO
|
||||
- "ti,twl4030-vio" for VIO LDO
|
||||
- "ti,twl4030-vdd1" for VDD1 SMPS
|
||||
- "ti,twl4030-vdd2" for VDD2 SMPS
|
||||
- "ti,twl4030-vintana1" for VINTANA1 LDO
|
||||
- "ti,twl4030-vintdig" for VINTDIG LDO
|
||||
- "ti,twl4030-vusb1v5" for VUSB1V5 LDO
|
||||
- "ti,twl4030-vusb1v8" for VUSB1V8 LDO
|
||||
- "ti,twl4030-vusb3v1" for VUSB3V1 LDO
|
||||
|
||||
Optional properties:
|
||||
- Any optional property defined in bindings/regulator/regulator.txt
|
||||
|
||||
Example:
|
||||
|
||||
xyz: regulator@0 {
|
||||
compatible = "ti,twl6030-vaux1";
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3000000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
ALC5632 audio CODEC
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "realtek,alc5632"
|
||||
|
||||
- reg : the I2C address of the device.
|
||||
|
||||
- gpio-controller : Indicates this device is a GPIO controller.
|
||||
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters (currently unused).
|
||||
|
||||
Example:
|
||||
|
||||
alc5632: alc5632@1e {
|
||||
compatible = "realtek,alc5632";
|
||||
reg = <0x1a>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
Freescale Digital Audio Mux (AUDMUX) device
|
||||
|
||||
Required properties:
|
||||
- compatible : "fsl,imx21-audmux" for AUDMUX version firstly used on i.MX21,
|
||||
or "fsl,imx31-audmux" for the version firstly used on i.MX31.
|
||||
- reg : Should contain AUDMUX registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
audmux@021d8000 {
|
||||
compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux";
|
||||
reg = <0x021d8000 0x4000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
NVIDIA Tegra audio complex
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra-audio-alc5632"
|
||||
- nvidia,model : The user-visible name of this sound complex.
|
||||
- nvidia,audio-routing : A list of the connections between audio components.
|
||||
Each entry is a pair of strings, the first being the connection's sink,
|
||||
the second being the connection's source. Valid names for sources and
|
||||
sinks are the ALC5632's pins:
|
||||
|
||||
ALC5632 pins:
|
||||
|
||||
* SPK_OUTP
|
||||
* SPK_OUTN
|
||||
* HP_OUT_L
|
||||
* HP_OUT_R
|
||||
* AUX_OUT_P
|
||||
* AUX_OUT_N
|
||||
* LINE_IN_L
|
||||
* LINE_IN_R
|
||||
* PHONE_P
|
||||
* PHONE_N
|
||||
* MIC1_P
|
||||
* MIC1_N
|
||||
* MIC2_P
|
||||
* MIC2_N
|
||||
* MICBIAS1
|
||||
* DMICDAT
|
||||
|
||||
Board connectors:
|
||||
|
||||
* Headset Stereophone
|
||||
* Int Spk
|
||||
* Headset Mic
|
||||
* Digital Mic
|
||||
|
||||
- nvidia,i2s-controller : The phandle of the Tegra I2S controller
|
||||
- nvidia,audio-codec : The phandle of the ALC5632 audio codec
|
||||
|
||||
Example:
|
||||
|
||||
sound {
|
||||
compatible = "nvidia,tegra-audio-alc5632-paz00",
|
||||
"nvidia,tegra-audio-alc5632";
|
||||
|
||||
nvidia,model = "Compal PAZ00";
|
||||
|
||||
nvidia,audio-routing =
|
||||
"Int Spk", "SPK_OUTP",
|
||||
"Int Spk", "SPK_OUTN",
|
||||
"Headset Mic","MICBIAS1",
|
||||
"MIC1_N", "Headset Mic",
|
||||
"MIC1_P", "Headset Mic",
|
||||
"Headset Stereophone", "HP_OUT_R",
|
||||
"Headset Stereophone", "HP_OUT_L";
|
||||
|
||||
nvidia,i2s-controller = <&tegra_i2s1>;
|
||||
nvidia,audio-codec = <&alc5632>;
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
OMAP2+ McSPI device
|
||||
|
||||
Required properties:
|
||||
- compatible :
|
||||
- "ti,omap2-spi" for OMAP2 & OMAP3.
|
||||
- "ti,omap4-spi" for OMAP4+.
|
||||
- ti,spi-num-cs : Number of chipselect supported by the instance.
|
||||
- ti,hwmods: Name of the hwmod associated to the McSPI
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
mcspi1: mcspi@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "ti,omap4-mcspi";
|
||||
ti,hwmods = "mcspi1";
|
||||
ti,spi-num-cs = <4>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
* Energymicro efm32 UART
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "efm32,uart"
|
||||
- reg : Address and length of the register set
|
||||
- interrupts : Should contain uart interrupt
|
||||
|
||||
Example:
|
||||
|
||||
uart@0x4000c400 {
|
||||
compatible = "efm32,uart";
|
||||
reg = <0x4000c400 0x400>;
|
||||
interrupts = <15>;
|
||||
};
|
||||
|
|
@ -34,6 +34,7 @@ picochip Picochip Ltd
|
|||
powervr Imagination Technologies
|
||||
qcom Qualcomm, Inc.
|
||||
ramtron Ramtron International
|
||||
realtek Realtek Semiconductor Corp.
|
||||
samsung Samsung Semiconductor
|
||||
sbs Smart Battery System
|
||||
schindler Schindler
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ it with special cases.
|
|||
|
||||
b) Entry with a flattened device-tree block. Firmware loads the
|
||||
physical address of the flattened device tree block (dtb) into r2,
|
||||
r1 is not used, but it is considered good practise to use a valid
|
||||
r1 is not used, but it is considered good practice to use a valid
|
||||
machine number as described in Documentation/arm/Booting.
|
||||
|
||||
r0 : 0
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ The slave DMA usage consists of following steps:
|
|||
struct dma_slave_config *config)
|
||||
|
||||
Please see the dma_slave_config structure definition in dmaengine.h
|
||||
for a detailed explaination of the struct members. Please note
|
||||
for a detailed explanation of the struct members. Please note
|
||||
that the 'direction' member will be going away as it duplicates the
|
||||
direction given in the prepare call.
|
||||
|
||||
|
|
|
|||
|
|
@ -271,3 +271,8 @@ IOMAP
|
|||
pcim_iounmap()
|
||||
pcim_iomap_table() : array of mapped addresses indexed by BAR
|
||||
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
|
||||
|
||||
REGULATOR
|
||||
devm_regulator_get()
|
||||
devm_regulator_put()
|
||||
devm_regulator_bulk_get()
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ dynamically enabled per-callsite.
|
|||
Dynamic debug has even more useful features:
|
||||
|
||||
* Simple query language allows turning on and off debugging statements by
|
||||
matching any combination of:
|
||||
matching any combination of 0 or 1 of:
|
||||
|
||||
- source filename
|
||||
- function name
|
||||
|
|
@ -79,31 +79,24 @@ Command Language Reference
|
|||
==========================
|
||||
|
||||
At the lexical level, a command comprises a sequence of words separated
|
||||
by whitespace characters. Note that newlines are treated as word
|
||||
separators and do *not* end a command or allow multiple commands to
|
||||
be done together. So these are all equivalent:
|
||||
by spaces or tabs. So these are all equivalent:
|
||||
|
||||
nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c ' file svcsock.c line 1603 +p ' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
Commands are bounded by a write() system call. If you want to do
|
||||
multiple commands you need to do a separate "echo" for each, like:
|
||||
Command submissions are bounded by a write() system call.
|
||||
Multiple commands can be written together, separated by ';' or '\n'.
|
||||
|
||||
nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\
|
||||
> echo 'file svcsock.c line 1563 +p' > /proc/dprintk
|
||||
~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
|
||||
> <debugfs>/dynamic_debug/control
|
||||
|
||||
or even like:
|
||||
If your query set is big, you can batch them too:
|
||||
|
||||
nullarbor:~ # (
|
||||
> echo 'file svcsock.c line 1603 +p' ;\
|
||||
> echo 'file svcsock.c line 1563 +p' ;\
|
||||
> ) > /proc/dprintk
|
||||
~# cat query-batch-file > <debugfs>/dynamic_debug/control
|
||||
|
||||
At the syntactical level, a command comprises a sequence of match
|
||||
specifications, followed by a flags change specification.
|
||||
|
|
@ -144,11 +137,12 @@ func
|
|||
func svc_tcp_accept
|
||||
|
||||
file
|
||||
The given string is compared against either the full
|
||||
pathname or the basename of the source file of each
|
||||
callsite. Examples:
|
||||
The given string is compared against either the full pathname, the
|
||||
src-root relative pathname, or the basename of the source file of
|
||||
each callsite. Examples:
|
||||
|
||||
file svcsock.c
|
||||
file kernel/freezer.c
|
||||
file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
|
||||
|
||||
module
|
||||
|
|
|
|||
|
|
@ -177,8 +177,8 @@ sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
|
|||
effect without `init'.
|
||||
sdram - tells to driver that you have Gxx0 with SDRAM memory.
|
||||
It is a default.
|
||||
inv24 - change timings parameters for 24bpp modes on Millenium and
|
||||
Millenium II. Specify this if you see strange color shadows around
|
||||
inv24 - change timings parameters for 24bpp modes on Millennium and
|
||||
Millennium II. Specify this if you see strange color shadows around
|
||||
characters.
|
||||
noinv24 - use standard timings. It is the default.
|
||||
inverse - invert colors on screen (for LCD displays)
|
||||
|
|
@ -204,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
|
|||
can paint colors.
|
||||
nograyscale - disable grayscale summing. It is default.
|
||||
cross4MB - enables that pixel line can cross 4MB boundary. It is default for
|
||||
non-Millenium.
|
||||
non-Millennium.
|
||||
nocross4MB - pixel line must not cross 4MB boundary. It is default for
|
||||
Millenium I or II, because of these devices have hardware
|
||||
Millennium I or II, because of these devices have hardware
|
||||
limitations which do not allow this. But this option is
|
||||
incompatible with some (if not all yet released) versions of
|
||||
XF86_FBDev.
|
||||
|
|
|
|||
|
|
@ -524,3 +524,22 @@ Files: arch/arm/mach-at91/at91cap9.c
|
|||
Why: The code is not actively maintained and platforms are now hard to find.
|
||||
Who: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
||||
When: 3.6
|
||||
Why: This driver provides support for USB storage devices like "USB
|
||||
sticks". As of now, it is deactivated in Debian, Fedora and
|
||||
Ubuntu. All current users can switch over to usb-storage
|
||||
(CONFIG_USB_STORAGE) which only drawback is the additional SCSI
|
||||
stack.
|
||||
Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: kmap_atomic(page, km_type)
|
||||
When: 3.5
|
||||
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
||||
keep it for backward compatibility for few cycles and then drop it.
|
||||
Who: Cong Wang <amwang@redhat.com>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,10 @@ Debugfs is typically mounted with a command like:
|
|||
|
||||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
(Or an equivalent /etc/fstab line).
|
||||
(Or an equivalent /etc/fstab line).
|
||||
The debugfs root directory is accessible by anyone by default. To
|
||||
restrict access to the tree the "uid", "gid" and "mode" mount
|
||||
options can be used.
|
||||
|
||||
Note that the debugfs API is exported GPL-only to modules.
|
||||
|
||||
|
|
@ -133,7 +136,7 @@ file.
|
|||
void __iomem *base;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_regset32(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_regset32 *regset);
|
||||
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ min_batch_time=usec This parameter sets the commit time (as
|
|||
fast disks, at the cost of increasing latency.
|
||||
|
||||
journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the
|
||||
highest priorty) which should be used for I/O
|
||||
highest priority) which should be used for I/O
|
||||
operations submitted by kjournald2 during a
|
||||
commit operation. This defaults to 3, which is
|
||||
a slightly higher priority than the default I/O
|
||||
|
|
@ -343,7 +343,7 @@ noinit_itable Do not initialize any uninitialized inode table
|
|||
init_itable=n The lazy itable init code will wait n times the
|
||||
number of milliseconds it took to zero out the
|
||||
previous block group's inode table. This
|
||||
minimizes the impact on the systme performance
|
||||
minimizes the impact on the system performance
|
||||
while file system's inode table is being initialized.
|
||||
|
||||
discard Controls whether ext4 should issue discard/TRIM
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ be fixed.
|
|||
|
||||
The REMOVE uevent is generated at the end of an unsuccessful mount
|
||||
or at the end of a umount of the filesystem. All REMOVE uevents will
|
||||
have been preceded by at least an ADD uevent for the same fileystem,
|
||||
have been preceded by at least an ADD uevent for the same filesystem,
|
||||
and unlike the other uevents is generated automatically by the kernel's
|
||||
kobject subsystem.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,21 @@ ID Mapper
|
|||
=========
|
||||
Id mapper is used by NFS to translate user and group ids into names, and to
|
||||
translate user and group names into ids. Part of this translation involves
|
||||
performing an upcall to userspace to request the information. Id mapper will
|
||||
user request-key to perform this upcall and cache the result. The program
|
||||
/usr/sbin/nfs.idmap should be called by request-key, and will perform the
|
||||
translation and initialize a key with the resulting information.
|
||||
performing an upcall to userspace to request the information. There are two
|
||||
ways NFS could obtain this information: placing a call to /sbin/request-key
|
||||
or by placing a call to the rpc.idmap daemon.
|
||||
|
||||
NFS will attempt to call /sbin/request-key first. If this succeeds, the
|
||||
result will be cached using the generic request-key cache. This call should
|
||||
only fail if /etc/request-key.conf is not configured for the id_resolver key
|
||||
type, see the "Configuring" section below if you wish to use the request-key
|
||||
method.
|
||||
|
||||
If the call to /sbin/request-key fails (if /etc/request-key.conf is not
|
||||
configured with the id_resolver key type), then the idmapper will ask the
|
||||
legacy rpc.idmap daemon for the id mapping. This result will be stored
|
||||
in a custom NFS idmap cache.
|
||||
|
||||
NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
|
||||
feature.
|
||||
|
||||
===========
|
||||
Configuring
|
||||
|
|
|
|||
|
|
@ -53,3 +53,57 @@ lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
|
|||
bit which holds it in the pnfs_layout_hdr's list. When the final lseg
|
||||
is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
|
||||
bit is set, preventing any new lsegs from being added.
|
||||
|
||||
layout drivers
|
||||
--------------
|
||||
|
||||
PNFS utilizes what is called layout drivers. The STD defines 3 basic
|
||||
layout types: "files" "objects" and "blocks". For each of these types
|
||||
there is a layout-driver with a common function-vectors table which
|
||||
are called by the nfs-client pnfs-core to implement the different layout
|
||||
types.
|
||||
|
||||
Files-layout-driver code is in: fs/nfs/nfs4filelayout.c && nfs4filelayoutdev.c
|
||||
Objects-layout-deriver code is in: fs/nfs/objlayout/.. directory
|
||||
Blocks-layout-deriver code is in: fs/nfs/blocklayout/.. directory
|
||||
|
||||
objects-layout setup
|
||||
--------------------
|
||||
|
||||
As part of the full STD implementation the objlayoutdriver.ko needs, at times,
|
||||
to automatically login to yet undiscovered iscsi/osd devices. For this the
|
||||
driver makes up-calles to a user-mode script called *osd_login*
|
||||
|
||||
The path_name of the script to use is by default:
|
||||
/sbin/osd_login.
|
||||
This name can be overridden by the Kernel module parameter:
|
||||
objlayoutdriver.osd_login_prog
|
||||
|
||||
If Kernel does not find the osd_login_prog path it will zero it out
|
||||
and will not attempt farther logins. An admin can then write new value
|
||||
to the objlayoutdriver.osd_login_prog Kernel parameter to re-enable it.
|
||||
|
||||
The /sbin/osd_login is part of the nfs-utils package, and should usually
|
||||
be installed on distributions that support this Kernel version.
|
||||
|
||||
The API to the login script is as follows:
|
||||
Usage: $0 -u <URI> -o <OSDNAME> -s <SYSTEMID>
|
||||
Options:
|
||||
-u target uri e.g. iscsi://<ip>:<port>
|
||||
(allways exists)
|
||||
(More protocols can be defined in the future.
|
||||
The client does not interpret this string it is
|
||||
passed unchanged as recieved from the Server)
|
||||
-o osdname of the requested target OSD
|
||||
(Might be empty)
|
||||
(A string which denotes the OSD name, there is a
|
||||
limit of 64 chars on this string)
|
||||
-s systemid of the requested target OSD
|
||||
(Might be empty)
|
||||
(This string, if not empty is always an hex
|
||||
representation of the 20 bytes osd_system_id)
|
||||
|
||||
blocks-layout setup
|
||||
-------------------
|
||||
|
||||
TODO: Document the setup needs of the blocks layout driver
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
|
|||
so one can extend protocol as needed without breaking backward compatibility as long
|
||||
as old commands are supported. All string lengths include tail 0 byte.
|
||||
|
||||
All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
|
||||
All commands are transferred over the network in big-endian. CPU endianness is used at the end peers.
|
||||
|
||||
@cmd - command number, which specifies command to be processed. Following
|
||||
commands are used currently:
|
||||
|
|
|
|||
|
|
@ -429,3 +429,9 @@ filemap_write_and_wait_range() so that all dirty pages are synced out properly.
|
|||
You must also keep in mind that ->fsync() is not called with i_mutex held
|
||||
anymore, so if you require i_mutex locking you must make sure to take it and
|
||||
release it yourself.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
d_alloc_root() is gone, along with a lot of bugs caused by code
|
||||
misusing it. Replacement: d_make_root(inode). The difference is,
|
||||
d_make_root() drops the reference to inode if dentry allocation fails.
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
|
|||
rsslim current limit in bytes on the rss
|
||||
start_code address above which program text can run
|
||||
end_code address below which program text can run
|
||||
start_stack address of the start of the stack
|
||||
start_stack address of the start of the main process stack
|
||||
esp current value of ESP
|
||||
eip current value of EIP
|
||||
pending bitmap of pending signals
|
||||
|
|
@ -325,7 +325,7 @@ address perms offset dev inode pathname
|
|||
a7cb1000-a7cb2000 ---p 00000000 00:00 0
|
||||
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
|
||||
a7eb2000-a7eb3000 ---p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack:1001]
|
||||
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
|
||||
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
|
||||
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
|
||||
|
|
@ -357,11 +357,39 @@ is not associated with a file:
|
|||
|
||||
[heap] = the heap of the program
|
||||
[stack] = the stack of the main process
|
||||
[stack:1001] = the stack of the thread with tid 1001
|
||||
[vdso] = the "virtual dynamic shared object",
|
||||
the kernel system call handler
|
||||
|
||||
or if empty, the mapping is anonymous.
|
||||
|
||||
The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
|
||||
of the individual tasks of a process. In this file you will see a mapping marked
|
||||
as [stack] if that task sees it as a stack. This is a key difference from the
|
||||
content of /proc/PID/maps, where you will see all mappings that are being used
|
||||
as stack by all of those tasks. Hence, for the example above, the task-level
|
||||
map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this:
|
||||
|
||||
08048000-08049000 r-xp 00000000 03:00 8312 /opt/test
|
||||
08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test
|
||||
0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
|
||||
a7cb1000-a7cb2000 ---p 00000000 00:00 0
|
||||
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
|
||||
a7eb2000-a7eb3000 ---p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack]
|
||||
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
|
||||
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
|
||||
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
|
||||
a800b000-a800e000 rw-p 00000000 00:00 0
|
||||
a800e000-a8022000 r-xp 00000000 03:00 14462 /lib/libpthread.so.0
|
||||
a8022000-a8023000 r--p 00013000 03:00 14462 /lib/libpthread.so.0
|
||||
a8023000-a8024000 rw-p 00014000 03:00 14462 /lib/libpthread.so.0
|
||||
a8024000-a8027000 rw-p 00000000 00:00 0
|
||||
a8027000-a8043000 r-xp 00000000 03:00 8317 /lib/ld-linux.so.2
|
||||
a8043000-a8044000 r--p 0001b000 03:00 8317 /lib/ld-linux.so.2
|
||||
a8044000-a8045000 rw-p 0001c000 03:00 8317 /lib/ld-linux.so.2
|
||||
aff35000-aff4a000 rw-p 00000000 00:00 0
|
||||
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
|
||||
|
||||
The /proc/PID/smaps is an extension based on maps, showing the memory
|
||||
consumption for each of the process's mappings. For each of mappings there
|
||||
|
|
|
|||
|
|
@ -0,0 +1,174 @@
|
|||
The QNX6 Filesystem
|
||||
===================
|
||||
|
||||
The qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino)
|
||||
It got introduced in QNX 6.4.0 and is used default since 6.4.1.
|
||||
|
||||
Option
|
||||
======
|
||||
|
||||
mmi_fs Mount filesystem as used for example by Audi MMI 3G system
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
qnx6fs shares many properties with traditional Unix filesystems. It has the
|
||||
concepts of blocks, inodes and directories.
|
||||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
running on a different endianess.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
Blocks
|
||||
------
|
||||
|
||||
The space in the device or file is split up into blocks. These are a fixed
|
||||
size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
|
||||
created.
|
||||
Blockpointers are 32bit, so the maximum space that can be adressed is
|
||||
2^32 * 4096 bytes or 16TB
|
||||
|
||||
The superblocks
|
||||
---------------
|
||||
|
||||
The superblock contains all global information about the filesystem.
|
||||
Each qnx6fs got two superblocks, each one having a 64bit serial number.
|
||||
That serial number is used to identify the "active" superblock.
|
||||
In write mode with reach new snapshot (after each synchronous write), the
|
||||
serial of the new master superblock is increased (old superblock serial + 1)
|
||||
|
||||
So basically the snapshot functionality is realized by an atomic final
|
||||
update of the serial number. Before updating that serial, all modifications
|
||||
are done by copying all modified blocks during that specific write request
|
||||
(or period) and building up a new (stable) filesystem structure under the
|
||||
inactive superblock.
|
||||
|
||||
Each superblock holds a set of root inodes for the different filesystem
|
||||
parts. (Inode, Bitmap and Longfilenames)
|
||||
Each of these root nodes holds information like total size of the stored
|
||||
data and the adressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be adressed by each
|
||||
node.
|
||||
Level 1 adds an additional indirect adressing level where each indirect
|
||||
adressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect adressig block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
|
||||
|
||||
Unused block pointers are always set to ~0 - regardless of root node,
|
||||
indirect adressing blocks or inodes.
|
||||
Data leaves are always on the lowest level. So no data is stored on upper
|
||||
tree levels.
|
||||
|
||||
The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
|
||||
The Audi MMI 3G first superblock directly starts at byte 0.
|
||||
Second superblock position can either be calculated from the superblock
|
||||
information (total number of filesystem blocks) or by taking the highest
|
||||
device address, zeroing the last 3 bytes and then substracting 0x1000 from
|
||||
that address.
|
||||
|
||||
0x1000 is the size reserved for each superblock - regardless of the
|
||||
blocksize of the filesystem.
|
||||
|
||||
Inodes
|
||||
------
|
||||
|
||||
Each object in the filesystem is represented by an inode. (index node)
|
||||
The inode structure contains pointers to the filesystem blocks which contain
|
||||
the data held in the object and all of the metadata about an object except
|
||||
its longname. (filenames longer than 27 characters)
|
||||
The metadata about an object includes the permissions, owner, group, flags,
|
||||
size, number of blocks used, access time, change time and modification time.
|
||||
|
||||
Object mode field is POSIX format. (which makes things easier)
|
||||
|
||||
There are also pointers to the first 16 blocks, if the object data can be
|
||||
adressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect adressing in form of another tree is
|
||||
used. (scheme is the same as the one used for the superblock root nodes)
|
||||
|
||||
The filesize is stored 64bit. Inode counting starts with 1. (whilst long
|
||||
filename inodes start with 0)
|
||||
|
||||
Directories
|
||||
-----------
|
||||
|
||||
A directory is a filesystem object and has an inode just like a file.
|
||||
It is a specially formatted file containing records which associate each
|
||||
name with an inode number.
|
||||
'.' inode number points to the directory inode
|
||||
'..' inode number points to the parent directory inode
|
||||
Eeach filename record additionally got a filename length field.
|
||||
|
||||
One special case are long filenames or subdirectory names.
|
||||
These got set a filename length field of 0xff in the corresponding directory
|
||||
record plus the longfile inode number also stored in that record.
|
||||
With that longfilename inode number, the longfilename tree can be walked
|
||||
starting with the superblock longfilename root node pointers.
|
||||
|
||||
Special files
|
||||
-------------
|
||||
|
||||
Symbolic links are also filesystem objects with inodes. They got a specific
|
||||
bit in the inode mode field identifying them as symbolic link.
|
||||
The directory entry file inode pointer points to the target file inode.
|
||||
|
||||
Hard links got an inode, a directory entry, but a specific mode bit set,
|
||||
no block pointers and the directory file record pointing to the target file
|
||||
inode.
|
||||
|
||||
Character and block special devices do not exist in QNX as those files
|
||||
are handled by the QNX kernel/drivers and created in /dev independant of the
|
||||
underlaying filesystem.
|
||||
|
||||
Long filenames
|
||||
--------------
|
||||
|
||||
Long filenames are stored in a seperate adressing tree. The staring point
|
||||
is the longfilename root node in the active superblock.
|
||||
Each data block (tree leaves) holds one long filename. That filename is
|
||||
limited to 510 bytes. The first two starting bytes are used as length field
|
||||
for the actual filename.
|
||||
If that structure shall fit for all allowed blocksizes, it is clear why there
|
||||
is a limit of 510 bytes for the actual filename stored.
|
||||
|
||||
Bitmap
|
||||
------
|
||||
|
||||
The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
|
||||
root node in the superblock and each bit in the bitmap represents one
|
||||
filesystem block.
|
||||
The first block is block 0, which starts 0x1000 after superblock start.
|
||||
So for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical
|
||||
address at which block 0 is located.
|
||||
|
||||
Bits at the end of the last bitmap block are set to 1, if the device is
|
||||
smaller than addressing space in the bitmap.
|
||||
|
||||
Bitmap system area
|
||||
------------------
|
||||
|
||||
The bitmap itself is devided into three parts.
|
||||
First the system area, that is split into two halfs.
|
||||
Then userspace.
|
||||
|
||||
The requirement for a static, fixed preallocated system area comes from how
|
||||
qnx6fs deals with writes.
|
||||
Each superblock got it's own half of the system area. So superblock #1
|
||||
always uses blocks from the lower half whilst superblock #2 just writes to
|
||||
blocks represented by the upper half bitmap system area bits.
|
||||
|
||||
Bitmap blocks, Inode blocks and indirect addressing blocks for those two
|
||||
tree structures are treated as system blocks.
|
||||
|
||||
The rational behind that is that a write request can work on a new snapshot
|
||||
(system area of the inactive - resp. lower serial numbered superblock) while
|
||||
at the same time there is still a complete stable filesystem structer in the
|
||||
other half of the system area.
|
||||
|
||||
When finished with writing (a sync write is completed, the maximum sync leap
|
||||
time or a filesystem sync is requested), serial of the previously inactive
|
||||
superblock atomically is increased and the fs switches over to that - then
|
||||
stable declared - superblock.
|
||||
|
||||
For all data outside the system area, blocks are just copied while writing.
|
||||
|
|
@ -297,7 +297,7 @@ the above threads) is:
|
|||
either way about the archive format, and there are alternative tools,
|
||||
such as:
|
||||
|
||||
http://freshmeat.net/projects/afio/
|
||||
http://freecode.com/projects/afio
|
||||
|
||||
2) The cpio archive format chosen by the kernel is simpler and cleaner (and
|
||||
thus easier to create and parse) than any of the (literally dozens of)
|
||||
|
|
|
|||
|
|
@ -993,7 +993,7 @@ struct dentry_operations {
|
|||
|
||||
If the 'rcu_walk' parameter is true, then the caller is doing a
|
||||
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
|
||||
and the caller can be asked to leave it and call again by returing
|
||||
and the caller can be asked to leave it and call again by returning
|
||||
-ECHILD.
|
||||
|
||||
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@ Kernel driver adm1275
|
|||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Analog Devices ADM1075
|
||||
Prefix: 'adm1075'
|
||||
Addresses scanned: -
|
||||
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1075.pdf
|
||||
* Analog Devices ADM1275
|
||||
Prefix: 'adm1275'
|
||||
Addresses scanned: -
|
||||
|
|
@ -17,13 +21,13 @@ Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276
|
||||
Hot-Swap Controller and Digital Power Monitor.
|
||||
This driver supports hardware montoring for Analog Devices ADM1075, ADM1275,
|
||||
and ADM1276 Hot-Swap Controller and Digital Power Monitor.
|
||||
|
||||
ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be
|
||||
removed from or inserted into a live backplane. They also feature current and
|
||||
voltage readback via an integrated 12-bit analog-to-digital converter (ADC),
|
||||
accessed using a PMBus interface.
|
||||
ADM1075, ADM1275, and ADM1276 are hot-swap controllers that allow a circuit
|
||||
board to be removed from or inserted into a live backplane. They also feature
|
||||
current and voltage readback via an integrated 12-bit analog-to-digital
|
||||
converter (ADC), accessed using a PMBus interface.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||
|
|
@ -36,6 +40,10 @@ This driver does not auto-detect devices. You will have to instantiate the
|
|||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
|
||||
The ADM1075, unlike many other PMBus devices, does not support internal voltage
|
||||
or current scaling. Reported voltages, currents, and power are raw measurements,
|
||||
and will typically have to be scaled.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
|
@ -51,9 +59,10 @@ The following attributes are supported. Limits are read-write, history reset
|
|||
attributes are write-only, all other attributes are read-only.
|
||||
|
||||
in1_label "vin1" or "vout1" depending on chip variant and
|
||||
configuration.
|
||||
configuration. On ADM1075, vout1 reports the voltage on
|
||||
the VAUX pin.
|
||||
in1_input Measured voltage.
|
||||
in1_min Minumum Voltage.
|
||||
in1_min Minimum Voltage.
|
||||
in1_max Maximum voltage.
|
||||
in1_min_alarm Voltage low alarm.
|
||||
in1_max_alarm Voltage high alarm.
|
||||
|
|
@ -74,3 +83,10 @@ curr1_crit Critical maximum current. Depending on the chip
|
|||
curr1_crit_alarm Critical current high alarm.
|
||||
curr1_highest Historical maximum current.
|
||||
curr1_reset_history Write any value to reset history.
|
||||
|
||||
power1_label "pin1"
|
||||
power1_input Input power.
|
||||
power1_reset_history Write any value to reset history.
|
||||
|
||||
Power attributes are supported on ADM1075 and ADM1276
|
||||
only.
|
||||
|
|
|
|||
|
|
@ -3,71 +3,50 @@ Kernel driver jc42
|
|||
|
||||
Supported chips:
|
||||
* Analog Devices ADT7408
|
||||
Prefix: 'adt7408'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
|
||||
* Atmel AT30TS00
|
||||
Prefix: 'at30ts00'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.atmel.com/Images/doc8585.pdf
|
||||
* IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
|
||||
Prefix: 'tse2002', 'ts3000'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TSE2002GB2A1_DST_20111107_120303145914.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TS3000B3A_DST_20101129_120303152013.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TS3000GB2A1_DST_20111104_120303151012.pdf
|
||||
* Maxim MAX6604
|
||||
Prefix: 'max6604'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
|
||||
* Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
|
||||
Prefixes: 'mcp9804', 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
|
||||
* NXP Semiconductors SE97, SE97B
|
||||
Prefix: 'se97'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
* NXP Semiconductors SE97, SE97B, SE98, SE98A
|
||||
Datasheets:
|
||||
http://www.nxp.com/documents/data_sheet/SE97.pdf
|
||||
http://www.nxp.com/documents/data_sheet/SE97B.pdf
|
||||
* NXP Semiconductors SE98
|
||||
Prefix: 'se98'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.nxp.com/documents/data_sheet/SE98.pdf
|
||||
http://www.nxp.com/documents/data_sheet/SE98A.pdf
|
||||
* ON Semiconductor CAT34TS02, CAT6095
|
||||
Prefix: 'cat34ts02', 'cat6095'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet:
|
||||
http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
|
||||
http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
|
||||
* ST Microelectronics STTS424, STTS424E02
|
||||
Prefix: 'stts424'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf
|
||||
http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf
|
||||
* ST Microelectronics STTS2002, STTS3000
|
||||
Prefix: 'stts2002', 'stts3000'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
* ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
|
||||
Datasheets:
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
|
||||
* JEDEC JC 42.4 compliant temperature sensor chips
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet:
|
||||
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
|
||||
|
||||
Common for all chips:
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
|
||||
Author:
|
||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,11 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
* National Semiconductor LM96080
|
||||
Prefix: 'lm96080'
|
||||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
|
|
@ -17,7 +22,9 @@ Description
|
|||
|
||||
This driver implements support for the National Semiconductor LM80.
|
||||
It is described as a 'Serial Interface ACPI-Compatible Microprocessor
|
||||
System Hardware Monitor'.
|
||||
System Hardware Monitor'. The LM96080 is a more recent incarnation,
|
||||
it is pin and register compatible, with a few additional features not
|
||||
yet supported by the driver.
|
||||
|
||||
The LM80 implements one temperature sensor, two fan rotation speed sensors,
|
||||
seven voltage sensors, alarms, and some miscellaneous stuff.
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ attributes are read-only.
|
|||
|
||||
in[1-4]_label "vout[1-4]"
|
||||
in[1-4]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
|
|||
|
|
@ -11,6 +11,11 @@ Supported chips:
|
|||
Prefixes: 'max34441'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
|
||||
* Maxim MAX34446
|
||||
PMBus Power-Supply Data Logger
|
||||
Prefixes: 'max34446'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
|
@ -19,8 +24,8 @@ Description
|
|||
-----------
|
||||
|
||||
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
|
||||
Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
|
||||
and Intelligent Fan Controller.
|
||||
Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
|
||||
and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||
|
|
@ -33,6 +38,13 @@ This driver does not auto-detect devices. You will have to instantiate the
|
|||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
|
||||
For MAX34446, the value of the currX_crit attribute determines if current or
|
||||
voltage measurement is enabled for a given channel. Voltage measurement is
|
||||
enabled if currX_crit is set to 0; current measurement is enabled if the
|
||||
attribute is set to a positive value. Power measurement is only enabled if
|
||||
channel 1 (3) is configured for voltage measurement, and channel 2 (4) is
|
||||
configured for current measurement.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
|
@ -48,27 +60,39 @@ attributes are read-only.
|
|||
|
||||
in[1-6]_label "vout[1-6]".
|
||||
in[1-6]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
|
||||
in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
in[1-6]_lowest Historical minimum voltage.
|
||||
in[1-6]_highest Historical maximum voltage.
|
||||
in[1-6]_reset_history Write any value to reset history.
|
||||
|
||||
MAX34446 only supports in[1-4].
|
||||
|
||||
curr[1-6]_label "iout[1-6]".
|
||||
curr[1-6]_input Measured current. From READ_IOUT register.
|
||||
curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
|
||||
curr[1-4]_average Historical average current (MAX34446 only).
|
||||
curr[1-6]_highest Historical maximum current.
|
||||
curr[1-6]_reset_history Write any value to reset history.
|
||||
|
||||
in6 and curr6 attributes only exist for MAX34440.
|
||||
MAX34446 only supports curr[1-4].
|
||||
|
||||
power[1,3]_label "pout[1,3]"
|
||||
power[1,3]_input Measured power.
|
||||
power[1,3]_average Historical average power.
|
||||
power[1,3]_highest Historical maximum power.
|
||||
|
||||
Power attributes only exist for MAX34446.
|
||||
|
||||
temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register.
|
||||
temp1 is the chip's internal temperature. temp2..temp5
|
||||
|
|
@ -79,7 +103,9 @@ temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register.
|
|||
temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register.
|
||||
temp[1-8]_max_alarm Temperature high alarm.
|
||||
temp[1-8]_crit_alarm Temperature critical high alarm.
|
||||
temp[1-8]_average Historical average temperature (MAX34446 only).
|
||||
temp[1-8]_highest Historical maximum temperature.
|
||||
temp[1-8]_reset_history Write any value to reset history.
|
||||
|
||||
temp7 and temp8 attributes only exist for MAX34440.
|
||||
MAX34446 only supports temp[1-3].
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ attributes are read-only.
|
|||
|
||||
in1_label "vout1"
|
||||
in1_input Measured voltage. From READ_VOUT register.
|
||||
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
|
|||
|
|
@ -15,13 +15,20 @@ Supported chips:
|
|||
http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF
|
||||
http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF
|
||||
* Lineage Power
|
||||
Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020'
|
||||
Prefixes: 'mdt040', 'pdt003', 'pdt006', 'pdt012', 'udt020'
|
||||
Addresses scanned: -
|
||||
Datasheets:
|
||||
http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/MDT040A0X.pdf
|
||||
* Texas Instruments TPS40400, TPS40422
|
||||
Prefixes: 'tps40400', 'tps40422'
|
||||
Addresses scanned: -
|
||||
Datasheets:
|
||||
http://www.ti.com/lit/gpn/tps40400
|
||||
http://www.ti.com/lit/gpn/tps40422
|
||||
* Generic PMBus devices
|
||||
Prefix: 'pmbus'
|
||||
Addresses scanned: -
|
||||
|
|
|
|||
|
|
@ -16,6 +16,11 @@ Description
|
|||
SMSC SCH5627 Super I/O chips include complete hardware monitoring
|
||||
capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.
|
||||
|
||||
The SMSC SCH5627 hardware monitoring part also contains an integrated
|
||||
watchdog. In order for this watchdog to function some motherboard specific
|
||||
initialization most be done by the BIOS, so if the watchdog is not enabled
|
||||
by the BIOS the sch5627 driver will not register a watchdog device.
|
||||
|
||||
The hardware monitoring part of the SMSC SCH5627 is accessed by talking
|
||||
through an embedded microcontroller. An application note describing the
|
||||
protocol for communicating with the microcontroller is available upon
|
||||
|
|
|
|||
|
|
@ -26,6 +26,9 @@ temperatures. Note that the driver detects how many fan headers /
|
|||
temperature sensors are actually implemented on the motherboard, so you will
|
||||
likely see fewer temperature and fan inputs.
|
||||
|
||||
The Fujitsu Theseus hwmon solution also contains an integrated watchdog.
|
||||
This watchdog is fully supported by the sch5636 driver.
|
||||
|
||||
An application note describing the Theseus' registers, as well as an
|
||||
application note describing the protocol for communicating with the
|
||||
microcontroller is available upon request. Please mail me if you want a copy.
|
||||
|
|
|
|||
|
|
@ -70,9 +70,9 @@ attributes are read-only.
|
|||
|
||||
in[1-12]_label "vout[1-12]".
|
||||
in[1-12]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-12]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-12]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-12]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-12]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
@ -82,7 +82,7 @@ in[1-12]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
|||
curr[1-12]_label "iout[1-12]".
|
||||
curr[1-12]_input Measured current. From READ_IOUT register.
|
||||
curr[1-12]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-12]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[1-12]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[1-12]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-12]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
|
|
|||
|
|
@ -54,9 +54,9 @@ attributes are read-only.
|
|||
|
||||
in1_label "vin".
|
||||
in1_input Measured voltage. From READ_VIN register.
|
||||
in1_min Minumum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VIN_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VIN_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VIN_OV_WARNING status.
|
||||
|
|
@ -65,9 +65,9 @@ in1_crit_alarm Voltage critical high alarm. From VIN_OV_FAULT status.
|
|||
|
||||
in[2-5]_label "vout[1-4]".
|
||||
in[2-5]_input Measured voltage. From READ_VOUT register.
|
||||
in[2-5]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[2-5]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[2-5]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[2-5]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
@ -80,7 +80,7 @@ curr1_input Measured current. From READ_IIN register.
|
|||
curr[2-5]_label "iout[1-4]".
|
||||
curr[2-5]_input Measured current. From READ_IOUT register.
|
||||
curr[2-5]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[2-5]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[2-5]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[2-5]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[2-5]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
|
|
|||
|
|
@ -34,6 +34,14 @@ Supported chips:
|
|||
Prefix: 'zl6105'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
|
||||
* Intersil / Zilker Labs ZL9101M
|
||||
Prefix: 'zl9101'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn7669.pdf
|
||||
* Intersil / Zilker Labs ZL9117M
|
||||
Prefix: 'zl9117'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn7914.pdf
|
||||
* Ericsson BMR450, BMR451
|
||||
Prefix: 'bmr450', 'bmr451'
|
||||
Addresses scanned: -
|
||||
|
|
@ -106,7 +114,7 @@ in1_label "vin"
|
|||
in1_input Measured input voltage.
|
||||
in1_min Minimum input voltage.
|
||||
in1_max Maximum input voltage.
|
||||
in1_lcrit Critical minumum input voltage.
|
||||
in1_lcrit Critical minimum input voltage.
|
||||
in1_crit Critical maximum input voltage.
|
||||
in1_min_alarm Input voltage low alarm.
|
||||
in1_max_alarm Input voltage high alarm.
|
||||
|
|
@ -115,7 +123,7 @@ in1_crit_alarm Input voltage critical high alarm.
|
|||
|
||||
in2_label "vout1"
|
||||
in2_input Measured output voltage.
|
||||
in2_lcrit Critical minumum output Voltage.
|
||||
in2_lcrit Critical minimum output Voltage.
|
||||
in2_crit Critical maximum output voltage.
|
||||
in2_lcrit_alarm Critical output voltage critical low alarm.
|
||||
in2_crit_alarm Critical output voltage critical high alarm.
|
||||
|
|
|
|||
|
|
@ -87,11 +87,11 @@ it may have different addresses from one board to the next (manufacturer
|
|||
changing its design without notice). In this case, you can call
|
||||
i2c_new_probed_device() instead of i2c_new_device().
|
||||
|
||||
Example (from the pnx4008 OHCI driver):
|
||||
Example (from the nxp OHCI driver):
|
||||
|
||||
static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
|
||||
|
||||
static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
||||
static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev)
|
||||
{
|
||||
(...)
|
||||
struct i2c_adapter *i2c_adap;
|
||||
|
|
@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
|||
(...)
|
||||
i2c_adap = i2c_get_adapter(2);
|
||||
memset(&i2c_info, 0, sizeof(struct i2c_board_info));
|
||||
strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE);
|
||||
strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE);
|
||||
isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
|
||||
normal_i2c, NULL);
|
||||
i2c_put_adapter(i2c_adap);
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ VI. Setting Parameters
|
|||
|
||||
The return value is the size in bytes of the data written into
|
||||
ops->resbuf if no errors occur. If an error occurs, -1 is returned
|
||||
and errno is set appropriatly:
|
||||
and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -222,7 +222,7 @@ VIII. Downloading Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -264,7 +264,7 @@ IX. Uploading Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -301,7 +301,7 @@ X. Removing Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -325,7 +325,7 @@ X. Validating Configuration
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no erro occur. If an error occurs, -1 is
|
||||
returned and errno is set appropriatly:
|
||||
returned and errno is set appropriately:
|
||||
|
||||
ETIMEDOUT Timeout waiting for reply message
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -360,7 +360,7 @@ XI. Configuration Dialog
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no error occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@
|
|||
* since the .pdf version doesn't seem to work...
|
||||
* -- Updated the TODO list to something more current.
|
||||
*
|
||||
* 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect mechine endianess,
|
||||
* 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect machine endianness,
|
||||
* patch thanks to "Eddie C. Dost" <ecd@skynet.be>
|
||||
*
|
||||
* 4.50 Oct 19, 1998 -- New maintainers!
|
||||
|
|
|
|||
|
|
@ -132,8 +132,8 @@ number of contacts (f1 and f0 in the table below).
|
|||
byte 5: 0 1 ? ? ? ? f1 f0
|
||||
|
||||
This packet only appears after a position packet with the mt bit set, and
|
||||
ususally only appears when there are two or more contacts (although
|
||||
ocassionally it's seen with only a single contact).
|
||||
usually only appears when there are two or more contacts (although
|
||||
occassionally it's seen with only a single contact).
|
||||
|
||||
The final v3 packet type is the trackstick packet.
|
||||
|
||||
|
|
|
|||
|
|
@ -330,7 +330,7 @@ the USB documentation for how to setup an USB mouse.
|
|||
The TM DirectConnect (BSP) protocol is supported by the tmdc.c
|
||||
module. This includes, but is not limited to:
|
||||
|
||||
* ThrustMaster Millenium 3D Inceptor
|
||||
* ThrustMaster Millennium 3D Interceptor
|
||||
* ThrustMaster 3D Rage Pad
|
||||
* ThrustMaster Fusion Digital Game Pad
|
||||
|
||||
|
|
|
|||
|
|
@ -596,7 +596,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile
|
|||
if CHS/LBA28
|
||||
|
||||
The association between in_flags.all and each enable
|
||||
bitfield flips depending on endianess; fortunately, TASKFILE
|
||||
bitfield flips depending on endianness; fortunately, TASKFILE
|
||||
only uses inflags.b.data bit and ignores all other bits.
|
||||
The end result is that, on any endian machines, it has no
|
||||
effect other than modifying in_flags on completion.
|
||||
|
|
@ -720,7 +720,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile
|
|||
|
||||
[6] Do not access {in|out}_flags->all except for resetting
|
||||
all the bits. Always access individual bit fields. ->all
|
||||
value will flip depending on endianess. For the same
|
||||
value will flip depending on endianness. For the same
|
||||
reason, do not use IDE_{TASKFILE|HOB}_STD_{OUT|IN}_FLAGS
|
||||
constants defined in hdreg.h.
|
||||
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ Code Seq#(hex) Include File Comments
|
|||
'Y' all linux/cyclades.h
|
||||
'Z' 14-15 drivers/message/fusion/mptctl.h
|
||||
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
|
||||
<mailto:gregkh@suse.de>
|
||||
<mailto:gregkh@linuxfoundation.org>
|
||||
'a' all linux/atm*.h, linux/sonet.h ATM on linux
|
||||
<http://lrcwww.epfl.ch/>
|
||||
'b' 00-FF conflict! bit3 vme host bridge
|
||||
|
|
@ -218,6 +218,7 @@ Code Seq#(hex) Include File Comments
|
|||
'h' 00-7F conflict! Charon filesystem
|
||||
<mailto:zapman@interlan.net>
|
||||
'h' 00-1F linux/hpet.h conflict!
|
||||
'h' 80-8F fs/hfsplus/ioctl.c
|
||||
'i' 00-3F linux/i2o-dev.h conflict!
|
||||
'i' 0B-1F linux/ipmi.h conflict!
|
||||
'i' 80-8F linux/i8k.h
|
||||
|
|
@ -255,7 +256,7 @@ Code Seq#(hex) Include File Comments
|
|||
linux/ixjuser.h <http://web.archive.org/web/*/http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
|
||||
's' all linux/cdk.h
|
||||
't' 00-7F linux/if_ppp.h
|
||||
't' 00-7F linux/ppp-ioctl.h
|
||||
't' 80-8F linux/isdn_ppp.h
|
||||
't' 90 linux/toshiba.h
|
||||
'u' 00-1F linux/smb_fs.h gone
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ applicable everywhere (see syntax).
|
|||
This attribute is only applicable to menu blocks, if the condition is
|
||||
false, the menu block is not displayed to the user (the symbols
|
||||
contained there can still be selected by other symbols, though). It is
|
||||
similar to a conditional "prompt" attribude for individual menu
|
||||
similar to a conditional "prompt" attribute for individual menu
|
||||
entries. Default value of "visible" is true.
|
||||
|
||||
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
||||
|
|
|
|||
|
|
@ -713,6 +713,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
The filter can be disabled or changed to another
|
||||
driver later using sysfs.
|
||||
|
||||
drm_kms_helper.edid_firmware=[<connector>:]<file>
|
||||
Broken monitors, graphic adapters and KVMs may
|
||||
send no or incorrect EDID data sets. This parameter
|
||||
allows to specify an EDID data set in the
|
||||
/lib/firmware directory that is used instead.
|
||||
Generic built-in EDID data sets are used, if one of
|
||||
edid/1024x768.bin, edid/1280x1024.bin,
|
||||
edid/1680x1050.bin, or edid/1920x1080.bin is given
|
||||
and no file with the same name exists. Details and
|
||||
instructions how to build your own EDID data are
|
||||
available in Documentation/EDID/HOWTO.txt. An EDID
|
||||
data set will only be used for a particular connector,
|
||||
if its name and a colon are prepended to the EDID
|
||||
name.
|
||||
|
||||
dscc4.setup= [NET]
|
||||
|
||||
earlycon= [KNL] Output early console device and options.
|
||||
|
|
@ -950,7 +965,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
controller
|
||||
i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
|
||||
controllers
|
||||
i8042.notimeout [HW] Ignore timeout condition signalled by conroller
|
||||
i8042.notimeout [HW] Ignore timeout condition signalled by controller
|
||||
i8042.reset [HW] Reset the controller during init and cleanup
|
||||
i8042.unlock [HW] Unlock (ignore) the keylock
|
||||
|
||||
|
|
@ -1657,6 +1672,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
of returning the full 64-bit number.
|
||||
The default is to return 64-bit inode numbers.
|
||||
|
||||
nfs.max_session_slots=
|
||||
[NFSv4.1] Sets the maximum number of session slots
|
||||
the client will attempt to negotiate with the server.
|
||||
This limits the number of simultaneous RPC requests
|
||||
that the client can send to the NFSv4.1 server.
|
||||
Note that there is little point in setting this
|
||||
value higher than the max_tcp_slot_table_limit.
|
||||
|
||||
nfs.nfs4_disable_idmapping=
|
||||
[NFSv4] When set to the default of '1', this option
|
||||
ensures that both the RPC level authentication
|
||||
|
|
@ -1670,6 +1693,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
back to using the idmapper.
|
||||
To turn off this behaviour, set the value to '0'.
|
||||
|
||||
nfs.send_implementation_id =
|
||||
[NFSv4.1] Send client implementation identification
|
||||
information in exchange_id requests.
|
||||
If zero, no implementation identification information
|
||||
will be sent.
|
||||
The default is to send the implementation identification
|
||||
information.
|
||||
|
||||
|
||||
objlayoutdriver.osd_login_prog=
|
||||
[NFS] [OBJLAYOUT] sets the pathname to the program which
|
||||
is used to automatically discover and login into new
|
||||
osd-targets. Please see:
|
||||
Documentation/filesystems/pnfs.txt for more explanations
|
||||
|
||||
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
|
||||
when a NMI is triggered.
|
||||
Format: [state][,regs][,debounce][,die]
|
||||
|
|
@ -2440,7 +2478,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
For more information see Documentation/vm/slub.txt.
|
||||
|
||||
slub_min_order= [MM, SLUB]
|
||||
Determines the mininum page order for slabs. Must be
|
||||
Determines the minimum page order for slabs. Must be
|
||||
lower than slub_max_order.
|
||||
For more information see Documentation/vm/slub.txt.
|
||||
|
||||
|
|
@ -2606,7 +2644,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
|
||||
threadirqs [KNL]
|
||||
Force threading of all interrupt handlers except those
|
||||
marked explicitely IRQF_NO_THREAD.
|
||||
marked explicitly IRQF_NO_THREAD.
|
||||
|
||||
topology= [S390]
|
||||
Format: {off | on}
|
||||
|
|
@ -2635,6 +2673,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
to facilitate early boot debugging.
|
||||
See also Documentation/trace/events.txt
|
||||
|
||||
transparent_hugepage=
|
||||
[KNL]
|
||||
Format: [always|madvise|never]
|
||||
Can be used to control the default behavior of the system
|
||||
with respect to transparent hugepages.
|
||||
See Documentation/vm/transhuge.txt for more details.
|
||||
|
||||
tsc= Disable clocksource stability checks for TSC.
|
||||
Format: <string>
|
||||
[x86] reliable: mark tsc clocksource as reliable, this
|
||||
|
|
|
|||
|
|
@ -354,7 +354,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는
|
|||
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||
|
||||
quilt trees:
|
||||
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@suse.de>
|
||||
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@linuxfoundation.org>
|
||||
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
- x86-64, partly i386, Andi Kleen < ak@suse.de>
|
||||
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Everything you never wanted to know about kobjects, ksets, and ktypes
|
||||
|
||||
Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
|
||||
Based on an original article by Jon Corbet for lwn.net written October 1,
|
||||
2003 and located at http://lwn.net/Articles/51437/
|
||||
|
|
|
|||
|
|
@ -43,17 +43,23 @@ Format: 10x mA i.e 10 means 1.0 mA
|
|||
example platform data:
|
||||
|
||||
Note: chan_nr can have values between 0 and 2.
|
||||
The name of each channel can be configurable.
|
||||
If the name field is not defined, the default name will be set to 'xxxx:channelN'
|
||||
(XXXX : pdata->label or i2c client name, N : channel number)
|
||||
|
||||
static struct lp5521_led_config lp5521_led_config[] = {
|
||||
{
|
||||
.name = "red",
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.name = "green",
|
||||
.chan_nr = 1,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.name = "blue",
|
||||
.chan_nr = 2,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
|
|
@ -86,3 +92,60 @@ static struct lp5521_platform_data lp5521_platform_data = {
|
|||
|
||||
If the current is set to 0 in the platform data, that channel is
|
||||
disabled and it is not visible in the sysfs.
|
||||
|
||||
The 'update_config' : CONFIG register (ADDR 08h)
|
||||
This value is platform-specific data.
|
||||
If update_config is not defined, the CONFIG register is set with
|
||||
'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
|
||||
(Enable auto-powersave, set charge pump to auto, red to battery)
|
||||
|
||||
example of update_config :
|
||||
|
||||
#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
|
||||
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
|
||||
LP5521_CLK_INT)
|
||||
|
||||
static struct lp5521_platform_data lp5521_pdata = {
|
||||
.led_config = lp5521_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||
.clock_mode = LP5521_CLOCK_INT,
|
||||
.update_config = LP5521_CONFIGS,
|
||||
};
|
||||
|
||||
LED patterns : LP5521 has autonomous operation without external control.
|
||||
Pattern data can be defined in the platform data.
|
||||
|
||||
example of led pattern data :
|
||||
|
||||
/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
|
||||
static u8 pattern_red[] = {
|
||||
0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
|
||||
};
|
||||
|
||||
static u8 pattern_green[] = {
|
||||
0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
|
||||
};
|
||||
|
||||
static struct lp5521_led_pattern board_led_patterns[] = {
|
||||
{
|
||||
.r = pattern_red,
|
||||
.g = pattern_green,
|
||||
.size_r = ARRAY_SIZE(pattern_red),
|
||||
.size_g = ARRAY_SIZE(pattern_green),
|
||||
},
|
||||
};
|
||||
|
||||
static struct lp5521_platform_data lp5521_platform_data = {
|
||||
.led_config = lp5521_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||
.clock_mode = LP5521_CLOCK_EXT,
|
||||
.patterns = board_led_patterns,
|
||||
.num_patterns = ARRAY_SIZE(board_led_patterns),
|
||||
};
|
||||
|
||||
Then predefined led pattern(s) can be executed via the sysfs.
|
||||
To start the pattern #1,
|
||||
# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
|
||||
(xxxx : i2c bus & slave address)
|
||||
To end the pattern,
|
||||
# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
===============================================================
|
||||
Softlockup detector and hardlockup detector (aka nmi_watchdog)
|
||||
===============================================================
|
||||
|
||||
The Linux kernel can act as a watchdog to detect both soft and hard
|
||||
lockups.
|
||||
|
||||
A 'softlockup' is defined as a bug that causes the kernel to loop in
|
||||
kernel mode for more than 20 seconds (see "Implementation" below for
|
||||
details), without giving other tasks a chance to run. The current
|
||||
stack trace is displayed upon detection and, by default, the system
|
||||
will stay locked up. Alternatively, the kernel can be configured to
|
||||
panic; a sysctl, "kernel.softlockup_panic", a kernel parameter,
|
||||
"softlockup_panic" (see "Documentation/kernel-parameters.txt" for
|
||||
details), and a compile option, "BOOTPARAM_HARDLOCKUP_PANIC", are
|
||||
provided for this.
|
||||
|
||||
A 'hardlockup' is defined as a bug that causes the CPU to loop in
|
||||
kernel mode for more than 10 seconds (see "Implementation" below for
|
||||
details), without letting other interrupts have a chance to run.
|
||||
Similarly to the softlockup case, the current stack trace is displayed
|
||||
upon detection and the system will stay locked up unless the default
|
||||
behavior is changed, which can be done through a compile time knob,
|
||||
"BOOTPARAM_HARDLOCKUP_PANIC", and a kernel parameter, "nmi_watchdog"
|
||||
(see "Documentation/kernel-parameters.txt" for details).
|
||||
|
||||
The panic option can be used in combination with panic_timeout (this
|
||||
timeout is set through the confusingly named "kernel.panic" sysctl),
|
||||
to cause the system to reboot automatically after a specified amount
|
||||
of time.
|
||||
|
||||
=== Implementation ===
|
||||
|
||||
The soft and hard lockup detectors are built on top of the hrtimer and
|
||||
perf subsystems, respectively. A direct consequence of this is that,
|
||||
in principle, they should work in any architecture where these
|
||||
subsystems are present.
|
||||
|
||||
A periodic hrtimer runs to generate interrupts and kick the watchdog
|
||||
task. An NMI perf event is generated every "watchdog_thresh"
|
||||
(compile-time initialized to 10 and configurable through sysctl of the
|
||||
same name) seconds to check for hardlockups. If any CPU in the system
|
||||
does not receive any hrtimer interrupt during that time the
|
||||
'hardlockup detector' (the handler for the NMI perf event) will
|
||||
generate a kernel warning or call panic, depending on the
|
||||
configuration.
|
||||
|
||||
The watchdog task is a high priority kernel thread that updates a
|
||||
timestamp every time it is scheduled. If that timestamp is not updated
|
||||
for 2*watchdog_thresh seconds (the softlockup threshold) the
|
||||
'softlockup detector' (coded inside the hrtimer callback function)
|
||||
will dump useful debug information to the system log, after which it
|
||||
will call panic if it was instructed to do so or resume execution of
|
||||
other kernel code.
|
||||
|
||||
The period of the hrtimer is 2*watchdog_thresh/5, which means it has
|
||||
two or three chances to generate an interrupt before the hardlockup
|
||||
detector kicks in.
|
||||
|
||||
As explained above, a kernel knob is provided that allows
|
||||
administrators to configure the period of the hrtimer and the perf
|
||||
event. The right value for a particular environment is a trade-off
|
||||
between fast response to lockups and detection overhead.
|
||||
|
|
@ -89,7 +89,7 @@ TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h
|
|||
MGSLPC_MAGIC 0x5402 mgslpc_info drivers/char/pcmcia/synclink_cs.c
|
||||
TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h
|
||||
USB_SERIAL_MAGIC 0x6702 usb_serial drivers/usb/serial/usb-serial.h
|
||||
FULL_DUPLEX_MAGIC 0x6969 drivers/net/tulip/de2104x.c
|
||||
FULL_DUPLEX_MAGIC 0x6969 drivers/net/ethernet/dec/tulip/de2104x.c
|
||||
USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c
|
||||
RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c
|
||||
USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue