Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
提交 7d7a48b7 编写于 作者: I Ingo Molnar
浏览文件
操作

Merge branch 'linus' into x86/urgent 

Merge reason: We want to queue up a dependent fix.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
上级 e4072a9a 229aebb8
展开全部 隐藏空白更改
内联 并排
Showing with 32334 addition and 8280 deletion

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
文本差异 电子邮件补丁
Documentation/ABI/testing/sysfs-ata 0 → 100644
浏览文件 @ 7d7a48b7
What: /sys/class/ata_...
Date: August 2008
Contact: Gwendal Grignou<gwendal@google.com>
Description:
Provide a place in sysfs for storing the ATA topology of the system. This allows
retrieving various information about ATA objects.
Files under /sys/class/ata_port
-------------------------------
For each port, a directory ataX is created where X is the ata_port_id of
the port. The device parent is the ata host device.
idle_irq (read)
Number of IRQ received by the port while idle [some ata HBA only].
nr_pmp_links (read)
If a SATA Port Multiplier (PM) is connected, number of link behind it.
Files under /sys/class/ata_link
-------------------------------
Behind each port, there is a ata_link. If there is a SATA PM in the
topology, 15 ata_link objects are created.
If a link is behind a port, the directory name is linkX, where X is
ata_port_id of the port.
If a link is behind a PM, its name is linkX.Y where X is ata_port_id
of the parent port and Y the PM port.
hw_sata_spd_limit
Maximum speed supported by the connected SATA device.
sata_spd_limit
Maximum speed imposed by libata.
sata_spd
Current speed of the link [1.5, 3Gps,...].
Files under /sys/class/ata_device
---------------------------------
Behind each link, up to two ata device are created.
The name of the directory is devX[.Y].Z where:
- X is ata_port_id of the port where the device is connected,
- Y the port of the PM if any, and
- Z the device id: for PATA, there is usually 2 devices [0,1],
only 1 for SATA.
class
Device class. Can be "ata" for disk, "atapi" for packet device,
"pmp" for PM, or "none" if no device was found behind the link.
dma_mode
Transfer modes supported by the device when in DMA mode.
Mostly used by PATA device.
pio_mode
Transfer modes supported by the device when in PIO mode.
Mostly used by PATA device.
xfer_mode
Current transfer mode.
id
Cached result of IDENTIFY command, as described in ATA8 7.16 and 7.17.
Only valid if the device is not a PM.
gscr
Cached result of the dump of PM GSCR register.
Valid registers are:
0: SATA_PMP_GSCR_PROD_ID,
1: SATA_PMP_GSCR_REV,
2: SATA_PMP_GSCR_PORT_INFO,
32: SATA_PMP_GSCR_ERROR,
33: SATA_PMP_GSCR_ERROR_EN,
64: SATA_PMP_GSCR_FEAT,
96: SATA_PMP_GSCR_FEAT_EN,
130: SATA_PMP_GSCR_SII_GPIO
Only valid if the device is a PM.
spdn_cnt
Number of time libata decided to lower the speed of link due to errors.
ering
Formatted output of the error ring of the device.
Documentation/ABI/testing/sysfs-devices-power
浏览文件 @ 7d7a48b7
...@@ -77,3 +77,91 @@ Description: ...@@ -77,3 +77,91 @@ Description:
devices this attribute is set to "enabled" by bus type code or devices this attribute is set to "enabled" by bus type code or
device drivers and in that cases it should be safe to leave the device drivers and in that cases it should be safe to leave the
default value. default value.
What: /sys/devices/.../power/wakeup_count
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_hit_count
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_hit_count attribute contains the
number of times the processing of a wakeup event associated with
the device might prevent the system from entering a sleep state.
This attribute is read-only. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_last_time_ms attribute contains
the value of the monotonic clock corresponding to the time of
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is empty.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
The /sys/devices/.../power/autosuspend_delay_ms attribute
contains the autosuspend delay value (in milliseconds). Some
drivers do not want their device to suspend as soon as it
becomes idle at run time; they want the device to remain
inactive for a certain minimum period of time first. That
period is called the autosuspend delay. Negative values will
prevent the device from being suspended at run time (similar
to writing "on" to the power/control attribute). Values >=
1000 will cause the autosuspend timer expiration to be rounded
up to the nearest second.
Not all drivers support this attribute. If it isn't supported,
attempts to read or write it will yield I/O errors.
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra 0 → 100644
浏览文件 @ 7d7a48b7
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_cpi
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: It is possible to switch the cpi setting of the mouse with the
press of a button.
When read, this file returns the raw number of the actual cpi
setting reported by the mouse. This number has to be further
processed to receive the real dpi value.
VALUE DPI
1 400
2 800
4 1600
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the settings stored in the mouse.
The size of the data is 3 bytes and holds information on the
startup_profile.
When written, this file lets write settings back to the mouse.
The data has to be 3 bytes long. The mouse will reject invalid
data.
Documentation/ABI/testing/sysfs-module 0 → 100644
浏览文件 @ 7d7a48b7
What: /sys/module/pch_phub/drivers/.../pch_mac
Date: August 2010
KernelVersion: 2.6.35
Contact: masa-korg@dsn.okisemi.com
Description: Write/read GbE MAC address.
What: /sys/module/pch_phub/drivers/.../pch_firmware
Date: August 2010
KernelVersion: 2.6.35
Contact: masa-korg@dsn.okisemi.com
Description: Write/read Option ROM data.
Documentation/ABI/testing/sysfs-power
浏览文件 @ 7d7a48b7
...@@ -99,9 +99,38 @@ Description: ...@@ -99,9 +99,38 @@ Description:
dmesg -s 1000000 | grep 'hash matches' dmesg -s 1000000 | grep 'hash matches'
If you do not get any matches (or they appear to be false
positives), it is possible that the last PM event point
referred to a device created by a loadable kernel module. In
this case cat /sys/power/pm_trace_dev_match (see below) after
your system is started up and the kernel modules are loaded.
CAUTION: Using it will cause your machine's real-time (CMOS) CAUTION: Using it will cause your machine's real-time (CMOS)
clock to be set to a random invalid time after a resume. clock to be set to a random invalid time after a resume.
What; /sys/power/pm_trace_dev_match
Date: October 2010
Contact: James Hogan <james@albanarts.com>
Description:
The /sys/power/pm_trace_dev_match file contains the name of the
device associated with the last PM event point saved in the RTC
across reboots when pm_trace has been used. More precisely it
contains the list of current devices (including those
registered by loadable kernel modules since boot) which match
the device hash in the RTC at boot, with a newline after each
one.
The advantage of this file over the hash matches printed to the
kernel log (see /sys/power/pm_trace), is that it includes
devices created after boot by loadable kernel modules.
Due to the small hash size necessary to fit in the RTC, it is
possible that more than one device matches the hash, in which
case further investigation is required to determine which
device is causing the problem. Note that genuine RTC clock
values (such as when pm_trace has not been used), can still
match a device and output it's name here.
What: /sys/power/pm_async What: /sys/power/pm_async
Date: January 2009 Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl> Contact: Rafael J. Wysocki <rjw@sisk.pl>
......
Documentation/DocBook/80211.tmpl 0 → 100644
浏览文件 @ 7d7a48b7
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<set>
<setinfo>
<title>The 802.11 subsystems &ndash; for kernel developers</title>
<subtitle>
Explaining wireless 802.11 networking in the Linux kernel
</subtitle>
<copyright>
<year>2007-2009</year>
<holder>Johannes Berg</holder>
</copyright>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation 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.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this documentation; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
<abstract>
<para>
These books attempt to give a description of the
various subsystems that play a role in 802.11 wireless
networking in Linux. Since these books are for kernel
developers they attempts to document the structures
and functions used in the kernel as well as giving a
higher-level overview.
</para>
<para>
The reader is expected to be familiar with the 802.11
standard as published by the IEEE in 802.11-2007 (or
possibly later versions). References to this standard
will be given as "802.11-2007 8.1.5".
</para>
</abstract>
</setinfo>
<book id="cfg80211-developers-guide">
<bookinfo>
<title>The cfg80211 subsystem</title>
<abstract>
!Pinclude/net/cfg80211.h Introduction
</abstract>
</bookinfo>
<chapter>
<title>Device registration</title>
!Pinclude/net/cfg80211.h Device registration
!Finclude/net/cfg80211.h ieee80211_band
!Finclude/net/cfg80211.h ieee80211_channel_flags
!Finclude/net/cfg80211.h ieee80211_channel
!Finclude/net/cfg80211.h ieee80211_rate_flags
!Finclude/net/cfg80211.h ieee80211_rate
!Finclude/net/cfg80211.h ieee80211_sta_ht_cap
!Finclude/net/cfg80211.h ieee80211_supported_band
!Finclude/net/cfg80211.h cfg80211_signal_type
!Finclude/net/cfg80211.h wiphy_params_flags
!Finclude/net/cfg80211.h wiphy_flags
!Finclude/net/cfg80211.h wiphy
!Finclude/net/cfg80211.h wireless_dev
!Finclude/net/cfg80211.h wiphy_new
!Finclude/net/cfg80211.h wiphy_register
!Finclude/net/cfg80211.h wiphy_unregister
!Finclude/net/cfg80211.h wiphy_free
!Finclude/net/cfg80211.h wiphy_name
!Finclude/net/cfg80211.h wiphy_dev
!Finclude/net/cfg80211.h wiphy_priv
!Finclude/net/cfg80211.h priv_to_wiphy
!Finclude/net/cfg80211.h set_wiphy_dev
!Finclude/net/cfg80211.h wdev_priv
</chapter>
<chapter>
<title>Actions and configuration</title>
!Pinclude/net/cfg80211.h Actions and configuration
!Finclude/net/cfg80211.h cfg80211_ops
!Finclude/net/cfg80211.h vif_params
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
!Finclude/net/cfg80211.h beacon_parameters
!Finclude/net/cfg80211.h plink_actions
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags
!Finclude/net/cfg80211.h rate_info
!Finclude/net/cfg80211.h station_info
!Finclude/net/cfg80211.h monitor_flags
!Finclude/net/cfg80211.h mpath_info_flags
!Finclude/net/cfg80211.h mpath_info
!Finclude/net/cfg80211.h bss_parameters
!Finclude/net/cfg80211.h ieee80211_txq_params
!Finclude/net/cfg80211.h cfg80211_crypto_settings
!Finclude/net/cfg80211.h cfg80211_auth_request
!Finclude/net/cfg80211.h cfg80211_assoc_request
!Finclude/net/cfg80211.h cfg80211_deauth_request
!Finclude/net/cfg80211.h cfg80211_disassoc_request
!Finclude/net/cfg80211.h cfg80211_ibss_params
!Finclude/net/cfg80211.h cfg80211_connect_params
!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
!Finclude/net/cfg80211.h __cfg80211_send_deauth
!Finclude/net/cfg80211.h cfg80211_send_disassoc
!Finclude/net/cfg80211.h __cfg80211_send_disassoc
!Finclude/net/cfg80211.h cfg80211_ibss_joined
!Finclude/net/cfg80211.h cfg80211_connect_result
!Finclude/net/cfg80211.h cfg80211_roamed
!Finclude/net/cfg80211.h cfg80211_disconnected
!Finclude/net/cfg80211.h cfg80211_ready_on_channel
!Finclude/net/cfg80211.h cfg80211_remain_on_channel_expired
!Finclude/net/cfg80211.h cfg80211_new_sta
!Finclude/net/cfg80211.h cfg80211_rx_mgmt
!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status
!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify
!Finclude/net/cfg80211.h cfg80211_michael_mic_failure
</chapter>
<chapter>
<title>Scanning and BSS list handling</title>
!Pinclude/net/cfg80211.h Scanning and BSS list handling
!Finclude/net/cfg80211.h cfg80211_ssid
!Finclude/net/cfg80211.h cfg80211_scan_request
!Finclude/net/cfg80211.h cfg80211_scan_done
!Finclude/net/cfg80211.h cfg80211_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss
!Finclude/net/cfg80211.h cfg80211_unlink_bss
!Finclude/net/cfg80211.h cfg80211_find_ie
!Finclude/net/cfg80211.h ieee80211_bss_get_ie
</chapter>
<chapter>
<title>Utility functions</title>
!Pinclude/net/cfg80211.h Utility functions
!Finclude/net/cfg80211.h ieee80211_channel_to_frequency
!Finclude/net/cfg80211.h ieee80211_frequency_to_channel
!Finclude/net/cfg80211.h ieee80211_get_channel
!Finclude/net/cfg80211.h ieee80211_get_response_rate
!Finclude/net/cfg80211.h ieee80211_hdrlen
!Finclude/net/cfg80211.h ieee80211_get_hdrlen_from_skb
!Finclude/net/cfg80211.h ieee80211_radiotap_iterator
</chapter>
<chapter>
<title>Data path helpers</title>
!Pinclude/net/cfg80211.h Data path helpers
!Finclude/net/cfg80211.h ieee80211_data_to_8023
!Finclude/net/cfg80211.h ieee80211_data_from_8023
!Finclude/net/cfg80211.h ieee80211_amsdu_to_8023s
!Finclude/net/cfg80211.h cfg80211_classify8021d
</chapter>
<chapter>
<title>Regulatory enforcement infrastructure</title>
!Pinclude/net/cfg80211.h Regulatory enforcement infrastructure
!Finclude/net/cfg80211.h regulatory_hint
!Finclude/net/cfg80211.h wiphy_apply_custom_regulatory
!Finclude/net/cfg80211.h freq_reg_info
</chapter>
<chapter>
<title>RFkill integration</title>
!Pinclude/net/cfg80211.h RFkill integration
!Finclude/net/cfg80211.h wiphy_rfkill_set_hw_state
!Finclude/net/cfg80211.h wiphy_rfkill_start_polling
!Finclude/net/cfg80211.h wiphy_rfkill_stop_polling
</chapter>
<chapter>
<title>Test mode</title>
!Pinclude/net/cfg80211.h Test mode
!Finclude/net/cfg80211.h cfg80211_testmode_alloc_reply_skb
!Finclude/net/cfg80211.h cfg80211_testmode_reply
!Finclude/net/cfg80211.h cfg80211_testmode_alloc_event_skb
!Finclude/net/cfg80211.h cfg80211_testmode_event
</chapter>
</book>
<book id="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem</title>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_vif
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Packet alignment</title>
!Pnet/mac80211/rx.c Packet alignment
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_info
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_wake_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="powersave">
<title>Powersave support</title>
!Pinclude/net/mac80211.h Powersave support
</chapter>
<chapter id="beacon-filter">
<title>Beacon filter support</title>
!Pinclude/net/mac80211.h Beacon filter support
!Finclude/net/mac80211.h ieee80211_beacon_loss
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>
</set>
Documentation/DocBook/Makefile
浏览文件 @ 7d7a48b7
...@@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ ...@@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml debugobjects.xml sh.xml regulator.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml media.xml drm.xml tracepoint.xml media.xml drm.xml
......
Documentation/DocBook/drm.tmpl
浏览文件 @ 7d7a48b7
...@@ -136,6 +136,7 @@ ...@@ -136,6 +136,7 @@
#ifdef CONFIG_COMPAT #ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl, .compat_ioctl = i915_compat_ioctl,
#endif #endif
.llseek = noop_llseek,
}, },
.pci_driver = { .pci_driver = {
.name = DRIVER_NAME, .name = DRIVER_NAME,
......
Documentation/DocBook/genericirq.tmpl
浏览文件 @ 7d7a48b7
...@@ -28,7 +28,7 @@ ...@@ -28,7 +28,7 @@
</authorgroup> </authorgroup>
<copyright> <copyright>
<year>2005-2006</year> <year>2005-2010</year>
<holder>Thomas Gleixner</holder> <holder>Thomas Gleixner</holder>
</copyright> </copyright>
<copyright> <copyright>
...@@ -100,6 +100,10 @@ ...@@ -100,6 +100,10 @@
<listitem><para>Edge type</para></listitem> <listitem><para>Edge type</para></listitem>
<listitem><para>Simple type</para></listitem> <listitem><para>Simple type</para></listitem>
</itemizedlist> </itemizedlist>
During the implementation we identified another type:
<itemizedlist>
<listitem><para>Fast EOI type</para></listitem>
</itemizedlist>
In the SMP world of the __do_IRQ() super-handler another type In the SMP world of the __do_IRQ() super-handler another type
was identified: was identified:
<itemizedlist> <itemizedlist>
...@@ -153,6 +157,7 @@ ...@@ -153,6 +157,7 @@
is still available. This leads to a kind of duality for the time is still available. This leads to a kind of duality for the time
being. Over time the new model should be used in more and more being. Over time the new model should be used in more and more
architectures, as it enables smaller and cleaner IRQ subsystems. architectures, as it enables smaller and cleaner IRQ subsystems.
It's deprecated for three years now and about to be removed.
</para> </para>
</chapter> </chapter>
<chapter id="bugs"> <chapter id="bugs">
...@@ -217,6 +222,7 @@ ...@@ -217,6 +222,7 @@
<itemizedlist> <itemizedlist>
<listitem><para>handle_level_irq</para></listitem> <listitem><para>handle_level_irq</para></listitem>
<listitem><para>handle_edge_irq</para></listitem> <listitem><para>handle_edge_irq</para></listitem>
<listitem><para>handle_fasteoi_irq</para></listitem>
<listitem><para>handle_simple_irq</para></listitem> <listitem><para>handle_simple_irq</para></listitem>
<listitem><para>handle_percpu_irq</para></listitem> <listitem><para>handle_percpu_irq</para></listitem>
</itemizedlist> </itemizedlist>
...@@ -233,33 +239,33 @@ ...@@ -233,33 +239,33 @@
are used by the default flow implementations. are used by the default flow implementations.
The following helper functions are implemented (simplified excerpt): The following helper functions are implemented (simplified excerpt):
<programlisting> <programlisting>
default_enable(irq) default_enable(struct irq_data *data)
{ {
desc->chip->unmask(irq); desc->chip->irq_unmask(data);
} }
default_disable(irq) default_disable(struct irq_data *data)
{ {
if (!delay_disable(irq)) if (!delay_disable(data))
desc->chip->mask(irq); desc->chip->irq_mask(data);
} }
default_ack(irq) default_ack(struct irq_data *data)
{ {
chip->ack(irq); chip->irq_ack(data);
} }
default_mask_ack(irq) default_mask_ack(struct irq_data *data)
{ {
if (chip->mask_ack) { if (chip->irq_mask_ack) {
chip->mask_ack(irq); chip->irq_mask_ack(data);
} else { } else {
chip->mask(irq); chip->irq_mask(data);
chip->ack(irq); chip->irq_ack(data);
} }
} }
noop(irq) noop(struct irq_data *data))
{ {
} }
...@@ -278,12 +284,27 @@ noop(irq) ...@@ -278,12 +284,27 @@ noop(irq)
<para> <para>
The following control flow is implemented (simplified excerpt): The following control flow is implemented (simplified excerpt):
<programlisting> <programlisting>
desc->chip->start(); desc->chip->irq_mask();
handle_IRQ_event(desc->action); handle_IRQ_event(desc->action);
desc->chip->end(); desc->chip->irq_unmask();
</programlisting> </programlisting>
</para> </para>
</sect3> </sect3>
<sect3 id="Default_FASTEOI_IRQ_flow_handler">
<title>Default Fast EOI IRQ flow handler</title>
<para>
handle_fasteoi_irq provides a generic implementation
for interrupts, which only need an EOI at the end of
the handler
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
desc->chip->irq_eoi();
</programlisting>
</para>
</sect3>
<sect3 id="Default_Edge_IRQ_flow_handler"> <sect3 id="Default_Edge_IRQ_flow_handler">
<title>Default Edge IRQ flow handler</title> <title>Default Edge IRQ flow handler</title>
<para> <para>
...@@ -294,20 +315,19 @@ desc->chip->end(); ...@@ -294,20 +315,19 @@ desc->chip->end();
The following control flow is implemented (simplified excerpt): The following control flow is implemented (simplified excerpt):
<programlisting> <programlisting>
if (desc->status &amp; running) { if (desc->status &amp; running) {
desc->chip->hold(); desc->chip->irq_mask();
desc->status |= pending | masked; desc->status |= pending | masked;
return; return;
} }
desc->chip->start(); desc->chip->irq_ack();
desc->status |= running; desc->status |= running;
do { do {
if (desc->status &amp; masked) if (desc->status &amp; masked)
desc->chip->enable(); desc->chip->irq_unmask();
desc->status &amp;= ~pending; desc->status &amp;= ~pending;
handle_IRQ_event(desc->action); handle_IRQ_event(desc->action);
} while (status &amp; pending); } while (status &amp; pending);
desc->status &amp;= ~running; desc->status &amp;= ~running;
desc->chip->end();
</programlisting> </programlisting>
</para> </para>
</sect3> </sect3>
...@@ -342,9 +362,9 @@ handle_IRQ_event(desc->action); ...@@ -342,9 +362,9 @@ handle_IRQ_event(desc->action);
<para> <para>
The following control flow is implemented (simplified excerpt): The following control flow is implemented (simplified excerpt):
<programlisting> <programlisting>
desc->chip->start();
handle_IRQ_event(desc->action); handle_IRQ_event(desc->action);
desc->chip->end(); if (desc->chip->irq_eoi)
desc->chip->irq_eoi();
</programlisting> </programlisting>
</para> </para>
</sect3> </sect3>
...@@ -375,8 +395,7 @@ desc->chip->end(); ...@@ -375,8 +395,7 @@ desc->chip->end();
mechanism. (It's necessary to enable CONFIG_HARDIRQS_SW_RESEND when mechanism. (It's necessary to enable CONFIG_HARDIRQS_SW_RESEND when
you want to use the delayed interrupt disable feature and your you want to use the delayed interrupt disable feature and your
hardware is not capable of retriggering an interrupt.) hardware is not capable of retriggering an interrupt.)
The delayed interrupt disable can be runtime enabled, per interrupt, The delayed interrupt disable is not configurable.
by setting the IRQ_DELAYED_DISABLE flag in the irq_desc status field.
</para> </para>
</sect2> </sect2>
</sect1> </sect1>
...@@ -387,13 +406,13 @@ desc->chip->end(); ...@@ -387,13 +406,13 @@ desc->chip->end();
contains all the direct chip relevant functions, which contains all the direct chip relevant functions, which
can be utilized by the irq flow implementations. can be utilized by the irq flow implementations.
<itemizedlist> <itemizedlist>
<listitem><para>ack()</para></listitem> <listitem><para>irq_ack()</para></listitem>
<listitem><para>mask_ack() - Optional, recommended for performance</para></listitem> <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>mask()</para></listitem> <listitem><para>irq_mask()</para></listitem>
<listitem><para>unmask()</para></listitem> <listitem><para>irq_unmask()</para></listitem>
<listitem><para>retrigger() - Optional</para></listitem> <listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>set_type() - Optional</para></listitem> <listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>set_wake() - Optional</para></listitem> <listitem><para>irq_set_wake() - Optional</para></listitem>
</itemizedlist> </itemizedlist>
These primitives are strictly intended to mean what they say: ack means These primitives are strictly intended to mean what they say: ack means
ACK, masking means masking of an IRQ line, etc. It is up to the flow ACK, masking means masking of an IRQ line, etc. It is up to the flow
...@@ -458,6 +477,7 @@ desc->chip->end(); ...@@ -458,6 +477,7 @@ desc->chip->end();
<para> <para>
This chapter contains the autogenerated documentation of the internal functions. This chapter contains the autogenerated documentation of the internal functions.
</para> </para>
!Ikernel/irq/irqdesc.c
!Ikernel/irq/handle.c !Ikernel/irq/handle.c
!Ikernel/irq/chip.c !Ikernel/irq/chip.c
</chapter> </chapter>
......
Documentation/DocBook/kernel-api.tmpl
浏览文件 @ 7d7a48b7
...@@ -257,7 +257,8 @@ X!Earch/x86/kernel/mca_32.c ...@@ -257,7 +257,8 @@ X!Earch/x86/kernel/mca_32.c
!Iblock/blk-sysfs.c !Iblock/blk-sysfs.c
!Eblock/blk-settings.c !Eblock/blk-settings.c
!Eblock/blk-exec.c !Eblock/blk-exec.c
!Eblock/blk-barrier.c !Eblock/blk-flush.c
!Eblock/blk-lib.c
!Eblock/blk-tag.c !Eblock/blk-tag.c
!Iblock/blk-tag.c !Iblock/blk-tag.c
!Eblock/blk-integrity.c !Eblock/blk-integrity.c
......
Documentation/DocBook/kernel-locking.tmpl
浏览文件 @ 7d7a48b7
...@@ -1645,7 +1645,9 @@ the amount of locking which needs to be done. ...@@ -1645,7 +1645,9 @@ the amount of locking which needs to be done.
all the readers who were traversing the list when we deleted the all the readers who were traversing the list when we deleted the
element are finished. We use <function>call_rcu()</function> to element are finished. We use <function>call_rcu()</function> to
register a callback which will actually destroy the object once register a callback which will actually destroy the object once
the readers are finished. all pre-existing readers are finished. Alternatively,
<function>synchronize_rcu()</function> may be used to block until
all pre-existing are finished.
</para> </para>
<para> <para>
But how does Read Copy Update know when the readers are But how does Read Copy Update know when the readers are
...@@ -1714,7 +1716,7 @@ the amount of locking which needs to be done. ...@@ -1714,7 +1716,7 @@ the amount of locking which needs to be done.
- object_put(obj); - object_put(obj);
+ list_del_rcu(&amp;obj-&gt;list); + list_del_rcu(&amp;obj-&gt;list);
cache_num--; cache_num--;
+ call_rcu(&amp;obj-&gt;rcu, cache_delete_rcu, obj); + call_rcu(&amp;obj-&gt;rcu, cache_delete_rcu);
} }
/* Must be holding cache_lock */ /* Must be holding cache_lock */
...@@ -1725,14 +1727,6 @@ the amount of locking which needs to be done. ...@@ -1725,14 +1727,6 @@ the amount of locking which needs to be done.
if (++cache_num > MAX_CACHE_SIZE) { if (++cache_num > MAX_CACHE_SIZE) {
struct object *i, *outcast = NULL; struct object *i, *outcast = NULL;
list_for_each_entry(i, &amp;cache, list) { list_for_each_entry(i, &amp;cache, list) {
@@ -85,6 +94,7 @@
obj-&gt;popularity = 0;
atomic_set(&amp;obj-&gt;refcnt, 1); /* The cache holds a reference */
spin_lock_init(&amp;obj-&gt;lock);
+ INIT_RCU_HEAD(&amp;obj-&gt;rcu);
spin_lock_irqsave(&amp;cache_lock, flags);
__cache_add(obj);
@@ -104,12 +114,11 @@ @@ -104,12 +114,11 @@
struct object *cache_find(int id) struct object *cache_find(int id)
{ {
......
Documentation/DocBook/mac80211.tmpl 已删除 100644 → 0
浏览文件 @ e4072a9a
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem for kernel developers</title>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2007-2009</year>
<holder>Johannes Berg</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation 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.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this documentation; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_vif
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Packet alignment</title>
!Pnet/mac80211/rx.c Packet alignment
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_info
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_wake_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_alg
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="powersave">
<title>Powersave support</title>
!Pinclude/net/mac80211.h Powersave support
</chapter>
<chapter id="beacon-filter">
<title>Beacon filter support</title>
!Pinclude/net/mac80211.h Beacon filter support
!Finclude/net/mac80211.h ieee80211_beacon_loss
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>
Documentation/RCU/checklist.txt
浏览文件 @ 7d7a48b7
...@@ -218,13 +218,22 @@ over a rather long period of time, but improvements are always welcome! ...@@ -218,13 +218,22 @@ over a rather long period of time, but improvements are always welcome!
include: include:
a. Keeping a count of the number of data-structure elements a. Keeping a count of the number of data-structure elements
used by the RCU-protected data structure, including those used by the RCU-protected data structure, including
waiting for a grace period to elapse. Enforce a limit those waiting for a grace period to elapse. Enforce a
on this number, stalling updates as needed to allow limit on this number, stalling updates as needed to allow
previously deferred frees to complete. previously deferred frees to complete. Alternatively,
limit only the number awaiting deferred free rather than
Alternatively, limit only the number awaiting deferred the total number of elements.
free rather than the total number of elements.
One way to stall the updates is to acquire the update-side
mutex. (Don't try this with a spinlock -- other CPUs
spinning on the lock could prevent the grace period
from ever ending.) Another way to stall the updates
is for the updates to use a wrapper function around
the memory allocator, so that this wrapper function
simulates OOM when there is too much memory awaiting an
RCU grace period. There are of course many other
variations on this theme.
b. Limiting update rate. For example, if updates occur only b. Limiting update rate. For example, if updates occur only
once per hour, then no explicit rate limiting is required, once per hour, then no explicit rate limiting is required,
...@@ -365,3 +374,26 @@ over a rather long period of time, but improvements are always welcome! ...@@ -365,3 +374,26 @@ over a rather long period of time, but improvements are always welcome!
and the compiler to freely reorder code into and out of RCU and the compiler to freely reorder code into and out of RCU
read-side critical sections. It is the responsibility of the read-side critical sections. It is the responsibility of the
RCU update-side primitives to deal with this. RCU update-side primitives to deal with this.
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
the __rcu sparse checks to validate your RCU code. These
can help find problems as follows:
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
structures are carried out under the proper RCU
read-side critical section, while holding the right
combination of locks, or whatever other conditions
are appropriate.
CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the
same object to call_rcu() (or friends) before an RCU
grace period has elapsed since the last time that you
passed that same object to call_rcu() (or friends).
__rcu sparse checks: tag the pointer to the RCU-protected data
structure with __rcu, and sparse will warn you if you
access that pointer without the services of one of the
variants of rcu_dereference().
These debugging aids can help you find problems that are
otherwise extremely difficult to spot.
Documentation/RCU/stallwarn.txt
浏览文件 @ 7d7a48b7
...@@ -80,6 +80,24 @@ o A CPU looping with bottom halves disabled. This condition can ...@@ -80,6 +80,24 @@ o A CPU looping with bottom halves disabled. This condition can
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
without invoking schedule(). without invoking schedule().
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
happen to preempt a low-priority task in the middle of an RCU
read-side critical section. This is especially damaging if
that low-priority task is not permitted to run on any other CPU,
in which case the next RCU grace period can never complete, which
will eventually cause the system to run out of memory and hang.
While the system is in the process of running itself out of
memory, you might see stall-warning messages.
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
is running at a higher priority than the RCU softirq threads.
This will prevent RCU callbacks from ever being invoked,
and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent
RCU grace periods from ever completing. Either way, the
system will eventually run out of memory and hang. In the
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
messages.
o A bug in the RCU implementation. o A bug in the RCU implementation.
o A hardware failure. This is quite unlikely, but has occurred o A hardware failure. This is quite unlikely, but has occurred
......
Documentation/RCU/trace.txt
浏览文件 @ 7d7a48b7
...@@ -125,6 +125,17 @@ o "b" is the batch limit for this CPU. If more than this number ...@@ -125,6 +125,17 @@ o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will of RCU callbacks is ready to invoke, then the remainder will
be deferred. be deferred.
o "ci" is the number of RCU callbacks that have been invoked for
this CPU. Note that ci+ql is the number of callbacks that have
been registered in absence of CPU-hotplug activity.
o "co" is the number of RCU callbacks that have been orphaned due to
this CPU going offline.
o "ca" is the number of RCU callbacks that have been adopted due to
other CPUs going offline. Note that ci+co-ca+ql is the number of
RCU callbacks registered on this CPU.
There is also an rcu/rcudata.csv file with the same information in There is also an rcu/rcudata.csv file with the same information in
comma-separated-variable spreadsheet format. comma-separated-variable spreadsheet format.
...@@ -180,7 +191,7 @@ o "s" is the "signaled" state that drives force_quiescent_state()'s ...@@ -180,7 +191,7 @@ o "s" is the "signaled" state that drives force_quiescent_state()'s
o "jfq" is the number of jiffies remaining for this grace period o "jfq" is the number of jiffies remaining for this grace period
before force_quiescent_state() is invoked to help push things before force_quiescent_state() is invoked to help push things
along. Note that CPUs in dyntick-idle mode thoughout the grace along. Note that CPUs in dyntick-idle mode throughout the grace
period will not report on their own, but rather must be check by period will not report on their own, but rather must be check by
some other CPU via force_quiescent_state(). some other CPU via force_quiescent_state().
......
Documentation/arm/00-INDEX
浏览文件 @ 7d7a48b7
...@@ -6,6 +6,8 @@ Interrupts ...@@ -6,6 +6,8 @@ Interrupts
- ARM Interrupt subsystem documentation - ARM Interrupt subsystem documentation
IXP2000 IXP2000
- Release Notes for Linux on Intel's IXP2000 Network Processor - Release Notes for Linux on Intel's IXP2000 Network Processor
msm
- MSM specific documentation
Netwinder Netwinder
- Netwinder specific documentation - Netwinder specific documentation
Porting Porting
......
Documentation/arm/SA1100/FreeBird
浏览文件 @ 7d7a48b7
Freebird-1.1 is produced by Legned(C) ,Inc. Freebird-1.1 is produced by Legend(C), Inc.
http://web.archive.org/web/*/http://www.legend.com.cn http://web.archive.org/web/*/http://www.legend.com.cn
and software/linux mainatined by Coventive(C),Inc. and software/linux maintained by Coventive(C), Inc.
(http://www.coventive.com) (http://www.coventive.com)
Based on the Nicolas's strongarm kernel tree. Based on the Nicolas's strongarm kernel tree.
......
Documentation/arm/msm/gpiomux.txt 0 → 100644
浏览文件 @ 7d7a48b7
This document provides an overview of the msm_gpiomux interface, which
is used to provide gpio pin multiplexing and configuration on mach-msm
targets.
History
=======
The first-generation API for gpio configuration & multiplexing on msm
is the function gpio_tlmm_config(). This function has a few notable
shortcomings, which led to its deprecation and replacement by gpiomux:
The 'disable' parameter: Setting the second parameter to
gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral
processor in charge of the subsystem to perform a look-up into a
low-power table and apply the low-power/sleep setting for the pin.
As the msm family evolved this became problematic. Not all pins
have sleep settings, not all peripheral processors will accept requests
to apply said sleep settings, and not all msm targets have their gpio
subsystems managed by a peripheral processor. In order to get consistent
behavior on all targets, drivers are forced to ignore this parameter,
rendering it useless.
The 'direction' flag: for all mux-settings other than raw-gpio (0),
the output-enable bit of a gpio is hard-wired to a known
input (usually VDD or ground). For those settings, the direction flag
is meaningless at best, and deceptive at worst. In addition, using the
direction flag to change output-enable (OE) directly can cause trouble in
gpiolib, which has no visibility into gpio direction changes made
in this way. Direction control in gpio mode should be made through gpiolib.
Key Features of gpiomux
=======================
- A consistent interface across all generations of msm. Drivers can expect
the same results on every target.
- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib
are left to gpiolib and not duplicated here. gpiomux is written with the
intent that gpio_chips will call gpiomux reference-counting methods
from their request() and free() hooks, providing full integration.
- Tabular configuration. Instead of having to call gpio_tlmm_config
hundreds of times, gpio configuration is placed in a single table.
- Per-gpio sleep. Each gpio is individually reference counted, allowing only
those lines which are in use to be put in high-power states.
- 0 means 'do nothing': all flags are designed so that the default memset-zero
equates to a sensible default of 'no configuration', preventing users
from having to provide hundreds of 'no-op' configs for unused or
unwanted lines.
Usage
=====
To use gpiomux, provide configuration information for relevant gpio lines
in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured",
only those lines to be managed by gpiomux need to be specified. Here
is a completely fictional example:
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
[12] = {
.active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1,
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
},
[34] = {
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
},
};
To indicate that a gpio is in use, call msm_gpiomux_get() to increase
its reference count. To decrease the reference count, call msm_gpiomux_put().
The effect of this configuration is as follows:
When the system boots, gpios 12 and 34 will be initialized with their
'suspended' configurations. All other gpios, which were left unconfigured,
will not be touched.
When msm_gpiomux_get() is called on gpio 12 to raise its reference count
above 0, its active configuration will be applied. Since no other gpio
line has a valid active configuration, msm_gpiomux_get() will have no
effect on any other line.
When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference
count to 0, their suspended configurations will be applied.
Since no other gpio line has a valid suspended configuration, no other
gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid
active configuration, this is effectively a no-op for gpio 34 as well,
with one small caveat, see the section "About Output-Enable Settings".
All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but
they address some important issues. As unused entries (all those
except 12 and 34) are zero-filled, gpiomux needs a way to distinguish
the used fields from the unused. In addition, the all-zero pattern
is a valid configuration! Therefore, gpiomux defines an additional bit
which is used to indicate when a field is used. This has the pleasant
side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate
that a value should not be changed:
msm_gpiomux_write(0, GPIOMUX_VALID, 0);
replaces the active configuration of gpio 0 with an all-zero configuration,
but leaves the suspended configuration as it was.
Static Configurations
=====================
To install a static configuration, which is applied at boot and does
not change after that, install a configuration with a suspended component
but no active component, as in the previous example:
[34] = {
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
},
The suspended setting is applied during boot, and the lack of any valid
active setting prevents any other setting from being applied at runtime.
If other subsystems attempting to access the line is a concern, one could
*really* anchor the configuration down by calling msm_gpiomux_get on the
line at initialization to move the line into active mode. With the line
held, it will never be re-suspended, and with no valid active configuration,
no new configurations will be applied.
But then, if having other subsystems grabbing for the line is truly a concern,
it should be reserved with gpio_request instead, which carries an implicit
msm_gpiomux_get.
gpiomux and gpiolib
===================
It is expected that msm gpio_chips will call msm_gpiomux_get() and
msm_gpiomux_put() from their request and free hooks, like this fictional
example:
static int request(struct gpio_chip *chip, unsigned offset)
{
return msm_gpiomux_get(chip->base + offset);
}
static void free(struct gpio_chip *chip, unsigned offset)
{
msm_gpiomux_put(chip->base + offset);
}
...somewhere in a gpio_chip declaration...
.request = request,
.free = free,
This provides important functionality:
- It guarantees that a gpio line will have its 'active' config applied
when the line is requested, and will not be suspended while the line
remains requested; and
- It guarantees that gpio-direction settings from gpiolib behave sensibly.
See "About Output-Enable Settings."
This mechanism allows for "auto-request" of gpiomux lines via gpiolib
when it is suitable. Drivers wishing more exact control are, of course,
free to also use msm_gpiomux_set and msm_gpiomux_get.
About Output-Enable Settings
============================
Some msm targets do not have the ability to query the current gpio
configuration setting. This means that changes made to the output-enable
(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux.
Therefore, when gpiomux applies a configuration setting, any direction
settings which may have been applied by gpiolib are lost and the default
input settings are re-applied.
For this reason, drivers should not assume that gpio direction settings
continue to hold if they free and then re-request a gpio. This seems like
common sense - after all, anybody could have obtained the line in the
meantime - but it needs saying.
This also means that calls to msm_gpiomux_write will reset the OE bit,
which means that if the gpio line is held by a client of gpiolib and
msm_gpiomux_write is called, the direction setting has been lost and
gpiolib's internal state has been broken.
Release gpio lines before reconfiguring them.
Documentation/block/00-INDEX
浏览文件 @ 7d7a48b7
00-INDEX 00-INDEX
- This file - This file
barrier.txt
- I/O Barriers
biodoc.txt biodoc.txt
- Notes on the Generic Block Layer Rewrite in Linux 2.5 - Notes on the Generic Block Layer Rewrite in Linux 2.5
capability.txt capability.txt
...@@ -16,3 +14,5 @@ stat.txt ...@@ -16,3 +14,5 @@ stat.txt
- Block layer statistics in /sys/block/<dev>/stat - Block layer statistics in /sys/block/<dev>/stat
switching-sched.txt switching-sched.txt
- Switching I/O schedulers at runtime - Switching I/O schedulers at runtime
writeback_cache_control.txt
- Control of volatile write back caches
Documentation/block/barrier.txt 已删除 100644 → 0
浏览文件 @ e4072a9a
I/O Barriers
============
Tejun Heo <htejun@gmail.com>, July 22 2005
I/O barrier requests are used to guarantee ordering around the barrier
requests. Unless you're crazy enough to use disk drives for
implementing synchronization constructs (wow, sounds interesting...),
the ordering is meaningful only for write requests for things like
journal checkpoints. All requests queued before a barrier request
must be finished (made it to the physical medium) before the barrier
request is started, and all requests queued after the barrier request
must be started only after the barrier request is finished (again,
made it to the physical medium).
In other words, I/O barrier requests have the following two properties.
1. Request ordering
Requests cannot pass the barrier request. Preceding requests are
processed before the barrier and following requests after.
Depending on what features a drive supports, this can be done in one
of the following three ways.
i. For devices which have queue depth greater than 1 (TCQ devices) and
support ordered tags, block layer can just issue the barrier as an
ordered request and the lower level driver, controller and drive
itself are responsible for making sure that the ordering constraint is
met. Most modern SCSI controllers/drives should support this.
NOTE: SCSI ordered tag isn't currently used due to limitation in the
SCSI midlayer, see the following random notes section.
ii. For devices which have queue depth greater than 1 but don't
support ordered tags, block layer ensures that the requests preceding
a barrier request finishes before issuing the barrier request. Also,
it defers requests following the barrier until the barrier request is
finished. Older SCSI controllers/drives and SATA drives fall in this
category.
iii. Devices which have queue depth of 1. This is a degenerate case
of ii. Just keeping issue order suffices. Ancient SCSI
controllers/drives and IDE drives are in this category.
2. Forced flushing to physical medium
Again, if you're not gonna do synchronization with disk drives (dang,
it sounds even more appealing now!), the reason you use I/O barriers
is mainly to protect filesystem integrity when power failure or some
other events abruptly stop the drive from operating and possibly make
the drive lose data in its cache. So, I/O barriers need to guarantee
that requests actually get written to non-volatile medium in order.
There are four cases,
i. No write-back cache. Keeping requests ordered is enough.
ii. Write-back cache but no flush operation. There's no way to
guarantee physical-medium commit order. This kind of devices can't to
I/O barriers.
iii. Write-back cache and flush operation but no FUA (forced unit
access). We need two cache flushes - before and after the barrier
request.
iv. Write-back cache, flush operation and FUA. We still need one
flush to make sure requests preceding a barrier are written to medium,
but post-barrier flush can be avoided by using FUA write on the
barrier itself.
How to support barrier requests in drivers
------------------------------------------
All barrier handling is done inside block layer proper. All low level
drivers have to are implementing its prepare_flush_fn and using one
the following two functions to indicate what barrier type it supports
and how to prepare flush requests. Note that the term 'ordered' is
used to indicate the whole sequence of performing barrier requests
including draining and flushing.
typedef void (prepare_flush_fn)(struct request_queue *q, struct request *rq);
int blk_queue_ordered(struct request_queue *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn);
@q : the queue in question
@ordered : the ordered mode the driver/device supports
@prepare_flush_fn : this function should prepare @rq such that it
flushes cache to physical medium when executed
For example, SCSI disk driver's prepare_flush_fn looks like the
following.
static void sd_prepare_flush(struct request_queue *q, struct request *rq)
{
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->timeout = SD_TIMEOUT;
rq->cmd[0] = SYNCHRONIZE_CACHE;
rq->cmd_len = 10;
}
The following seven ordered modes are supported. The following table
shows which mode should be used depending on what features a
device/driver supports. In the leftmost column of table,
QUEUE_ORDERED_ prefix is omitted from the mode names to save space.
The table is followed by description of each mode. Note that in the
descriptions of QUEUE_ORDERED_DRAIN*, '=>' is used whereas '->' is
used for QUEUE_ORDERED_TAG* descriptions. '=>' indicates that the
preceding step must be complete before proceeding to the next step.
'->' indicates that the next step can start as soon as the previous
step is issued.
write-back cache ordered tag flush FUA
-----------------------------------------------------------------------
NONE yes/no N/A no N/A
DRAIN no no N/A N/A
DRAIN_FLUSH yes no yes no
DRAIN_FUA yes no yes yes
TAG no yes N/A N/A
TAG_FLUSH yes yes yes no
TAG_FUA yes yes yes yes
QUEUE_ORDERED_NONE
I/O barriers are not needed and/or supported.
Sequence: N/A
QUEUE_ORDERED_DRAIN
Requests are ordered by draining the request queue and cache
flushing isn't needed.
Sequence: drain => barrier
QUEUE_ORDERED_DRAIN_FLUSH
Requests are ordered by draining the request queue and both
pre-barrier and post-barrier cache flushings are needed.
Sequence: drain => preflush => barrier => postflush
QUEUE_ORDERED_DRAIN_FUA
Requests are ordered by draining the request queue and
pre-barrier cache flushing is needed. By using FUA on barrier
request, post-barrier flushing can be skipped.
Sequence: drain => preflush => barrier
QUEUE_ORDERED_TAG
Requests are ordered by ordered tag and cache flushing isn't
needed.
Sequence: barrier
QUEUE_ORDERED_TAG_FLUSH
Requests are ordered by ordered tag and both pre-barrier and
post-barrier cache flushings are needed.
Sequence: preflush -> barrier -> postflush
QUEUE_ORDERED_TAG_FUA
Requests are ordered by ordered tag and pre-barrier cache
flushing is needed. By using FUA on barrier request,
post-barrier flushing can be skipped.
Sequence: preflush -> barrier
Random notes/caveats
--------------------
* SCSI layer currently can't use TAG ordering even if the drive,
controller and driver support it. The problem is that SCSI midlayer
request dispatch function is not atomic. It releases queue lock and
switch to SCSI host lock during issue and it's possible and likely to
happen in time that requests change their relative positions. Once
this problem is solved, TAG ordering can be enabled.
* Currently, no matter which ordered mode is used, there can be only
one barrier request in progress. All I/O barriers are held off by
block layer until the previous I/O barrier is complete. This doesn't
make any difference for DRAIN ordered devices, but, for TAG ordered
devices with very high command latency, passing multiple I/O barriers
to low level *might* be helpful if they are very frequent. Well, this
certainly is a non-issue. I'm writing this just to make clear that no
two I/O barrier is ever passed to low-level driver.
* Completion order. Requests in ordered sequence are issued in order
but not required to finish in order. Barrier implementation can
handle out-of-order completion of ordered sequence. IOW, the requests
MUST be processed in order but the hardware/software completion paths
are allowed to reorder completion notifications - eg. current SCSI
midlayer doesn't preserve completion order during error handling.
* Requeueing order. Low-level drivers are free to requeue any request
after they removed it from the request queue with
blkdev_dequeue_request(). As barrier sequence should be kept in order
when requeued, generic elevator code takes care of putting requests in
order around barrier. See blk_ordered_req_seq() and
ELEVATOR_INSERT_REQUEUE handling in __elv_add_request() for details.
Note that block drivers must not requeue preceding requests while
completing latter requests in an ordered sequence. Currently, no
error checking is done against this.
* Error handling. Currently, block layer will report error to upper
layer if any of requests in an ordered sequence fails. Unfortunately,
this doesn't seem to be enough. Look at the following request flow.
QUEUE_ORDERED_TAG_FLUSH is in use.
[0] [1] [2] [3] [pre] [barrier] [post] < [4] [5] [6] ... >
still in elevator
Let's say request [2], [3] are write requests to update file system
metadata (journal or whatever) and [barrier] is used to mark that
those updates are valid. Consider the following sequence.
i. Requests [0] ~ [post] leaves the request queue and enters
low-level driver.
ii. After a while, unfortunately, something goes wrong and the
drive fails [2]. Note that any of [0], [1] and [3] could have
completed by this time, but [pre] couldn't have been finished
as the drive must process it in order and it failed before
processing that command.
iii. Error handling kicks in and determines that the error is
unrecoverable and fails [2], and resumes operation.
iv. [pre] [barrier] [post] gets processed.
v. *BOOM* power fails
The problem here is that the barrier request is *supposed* to indicate
that filesystem update requests [2] and [3] made it safely to the
physical medium and, if the machine crashes after the barrier is
written, filesystem recovery code can depend on that. Sadly, that
isn't true in this case anymore. IOW, the success of a I/O barrier
should also be dependent on success of some of the preceding requests,
where only upper layer (filesystem) knows what 'some' is.
This can be solved by implementing a way to tell the block layer which
requests affect the success of the following barrier request and
making lower lever drivers to resume operation on error only after
block layer tells it to do so.
As the probability of this happening is very low and the drive should
be faulty, implementing the fix is probably an overkill. But, still,
it's there.
* In previous drafts of barrier implementation, there was fallback
mechanism such that, if FUA or ordered TAG fails, less fancy ordered
mode can be selected and the failed barrier request is retried
automatically. The rationale for this feature was that as FUA is
pretty new in ATA world and ordered tag was never used widely, there
could be devices which report to support those features but choke when
actually given such requests.
This was removed for two reasons 1. it's an overkill 2. it's
impossible to implement properly when TAG ordering is used as low
level drivers resume after an error automatically. If it's ever
needed adding it back and modifying low level drivers accordingly
shouldn't be difficult.
Documentation/block/writeback_cache_control.txt 0 → 100644
浏览文件 @ 7d7a48b7
Explicit volatile write back cache control
=====================================
Introduction
------------
Many storage devices, especially in the consumer market, come with volatile
write back caches. That means the devices signal I/O completion to the
operating system before data actually has hit the non-volatile storage. This
behavior obviously speeds up various workloads, but it means the operating
system needs to force data out to the non-volatile storage when it performs
a data integrity operation like fsync, sync or an unmount.
The Linux block layer provides two simple mechanisms that let filesystems
control the caching behavior of the storage device. These mechanisms are
a forced cache flush, and the Force Unit Access (FUA) flag for requests.
Explicit cache flushes
----------------------
The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from
the filesystem and will make sure the volatile cache of the storage device
has been flushed before the actual I/O operation is started. This explicitly
guarantees that previously completed write requests are on non-volatile
storage before the flagged bio starts. In addition the REQ_FLUSH flag can be
set on an otherwise empty bio structure, which causes only an explicit cache
flush without any dependent I/O. It is recommend to use
the blkdev_issue_flush() helper for a pure cache flush.
Forced Unit Access
-----------------
The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the
filesystem and will make sure that I/O completion for this request is only
signaled after the data has been committed to non-volatile storage.
Implementation details for filesystems
--------------------------------------
Filesystems can simply set the REQ_FLUSH and REQ_FUA bits and do not have to
worry if the underlying devices need any explicit cache flushing and how
the Forced Unit Access is implemented. The REQ_FLUSH and REQ_FUA flags
may both be set on a single bio.
Implementation details for make_request_fn based block drivers
--------------------------------------------------------------
These drivers will always see the REQ_FLUSH and REQ_FUA bits as they sit
directly below the submit_bio interface. For remapping drivers the REQ_FUA
bits need to be propagated to underlying devices, and a global flush needs
to be implemented for bios with the REQ_FLUSH bit set. For real device
drivers that do not have a volatile cache the REQ_FLUSH and REQ_FUA bits
on non-empty bios can simply be ignored, and REQ_FLUSH requests without
data can be completed successfully without doing any work. Drivers for
devices with volatile caches need to implement the support for these
flags themselves without any help from the block layer.
Implementation details for request_fn based block drivers
--------------------------------------------------------------
For devices that do not support volatile write caches there is no driver
support required, the block layer completes empty REQ_FLUSH requests before
entering the driver and strips off the REQ_FLUSH and REQ_FUA bits from
requests that have a payload. For devices with volatile write caches the
driver needs to tell the block layer that it supports flushing caches by
doing:
blk_queue_flush(sdkp->disk->queue, REQ_FLUSH);
and handle empty REQ_FLUSH requests in its prep_fn/request_fn. Note that
REQ_FLUSH requests with a payload are automatically turned into a sequence
of an empty REQ_FLUSH request followed by the actual write by the block
layer. For devices that also support the FUA bit the block layer needs
to be told to pass through the REQ_FUA bit using:
blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA);
and the driver must handle write requests that have the REQ_FUA bit set
in prep_fn/request_fn. If the FUA bit is not natively supported the block
layer turns it into an empty REQ_FLUSH request after the actual write.
Documentation/cgroups/blkio-controller.txt
浏览文件 @ 7d7a48b7
...@@ -8,12 +8,17 @@ both at leaf nodes as well as at intermediate nodes in a storage hierarchy. ...@@ -8,12 +8,17 @@ both at leaf nodes as well as at intermediate nodes in a storage hierarchy.
Plan is to use the same cgroup based management interface for blkio controller Plan is to use the same cgroup based management interface for blkio controller
and based on user options switch IO policies in the background. and based on user options switch IO policies in the background.
In the first phase, this patchset implements proportional weight time based Currently two IO control policies are implemented. First one is proportional
division of disk policy. It is implemented in CFQ. Hence this policy takes weight time based division of disk policy. It is implemented in CFQ. Hence
effect only on leaf nodes when CFQ is being used. this policy takes effect only on leaf nodes when CFQ is being used. The second
one is throttling policy which can be used to specify upper IO rate limits
on devices. This policy is implemented in generic block layer and can be
used on leaf nodes as well as higher level logical devices like device mapper.
HOWTO HOWTO
===== =====
Proportional Weight division of bandwidth
-----------------------------------------
You can do a very simple testing of running two dd threads in two different You can do a very simple testing of running two dd threads in two different
cgroups. Here is what you can do. cgroups. Here is what you can do.
...@@ -55,6 +60,35 @@ cgroups. Here is what you can do. ...@@ -55,6 +60,35 @@ cgroups. Here is what you can do.
group dispatched to the disk. We provide fairness in terms of disk time, so group dispatched to the disk. We provide fairness in terms of disk time, so
ideally io.disk_time of cgroups should be in proportion to the weight. ideally io.disk_time of cgroups should be in proportion to the weight.
Throttling/Upper Limit policy
-----------------------------
- Enable Block IO controller
CONFIG_BLK_CGROUP=y
- Enable throttling in block layer
CONFIG_BLK_DEV_THROTTLING=y
- Mount blkio controller
mount -t cgroup -o blkio none /cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
for policy is "<major>:<minor> <byes_per_second>".
echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Above will put a limit of 1MB/second on reads happening for root group
on device having major/minor number 8:16.
- Run dd to read a file and see if rate is throttled to 1MB/s or not.
# dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024
# iflag=direct
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s
Limits for writes can be put using blkio.write_bps_device file.
Various user visible config options Various user visible config options
=================================== ===================================
CONFIG_BLK_CGROUP CONFIG_BLK_CGROUP
...@@ -68,8 +102,13 @@ CONFIG_CFQ_GROUP_IOSCHED ...@@ -68,8 +102,13 @@ CONFIG_CFQ_GROUP_IOSCHED
- Enables group scheduling in CFQ. Currently only 1 level of group - Enables group scheduling in CFQ. Currently only 1 level of group
creation is allowed. creation is allowed.
CONFIG_BLK_DEV_THROTTLING
- Enable block device throttling support in block layer.
Details of cgroup files Details of cgroup files
======================= =======================
Proportional weight policy files
--------------------------------
- blkio.weight - blkio.weight
- Specifies per cgroup weight. This is default weight of the group - Specifies per cgroup weight. This is default weight of the group
on all the devices until and unless overridden by per device rule. on all the devices until and unless overridden by per device rule.
...@@ -210,6 +249,67 @@ Details of cgroup files ...@@ -210,6 +249,67 @@ Details of cgroup files
and minor number of the device and third field specifies the number and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device. of times a group was dequeued from a particular device.
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
the format.
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.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
the format.
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.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
the format.
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.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
the format.
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.write_iops_device
Note: If both BW and IOPS rules are specified for a device, then IO is
subjectd to both the constraints.
- blkio.throttle.io_serviced
- Number of IOs (bio) completed to/from the disk by the group (as
seen by throttling policy). These are further divided by the type
of operation - read or write, sync or async. First two fields specify
the major and minor number of the device, third field specifies the
operation type and the fourth field specifies the number of IOs.
blkio.io_serviced does accounting as seen by CFQ and counts are in
number of requests (struct request). On the other hand,
blkio.throttle.io_serviced counts number of IO in terms of number
of bios as seen by throttling policy. These bios can later be
merged by elevator and total number of requests completed can be
lesser.
- blkio.throttle.io_service_bytes
- Number of bytes transferred to/from the disk by the group. These
are further divided by the type of operation - read or write, sync
or async. First two fields specify the major and minor number of the
device, third field specifies the operation type and the fourth field
specifies the number of bytes.
These numbers should roughly be same as blkio.io_service_bytes as
updated by CFQ. The difference between two is that
blkio.io_service_bytes will not be updated if CFQ is not operating
on request queue.
Common files among various policies
-----------------------------------
- blkio.reset_stats - blkio.reset_stats
- Writing an int to this file will result in resetting all the stats - Writing an int to this file will result in resetting all the stats
for that cgroup. for that cgroup.
......
Documentation/cputopology.txt
浏览文件 @ 7d7a48b7
...@@ -14,25 +14,39 @@ to /proc/cpuinfo. ...@@ -14,25 +14,39 @@ to /proc/cpuinfo.
identifier (rather than the kernel's). The actual value is identifier (rather than the kernel's). The actual value is
architecture and platform dependent. architecture and platform dependent.
3) /sys/devices/system/cpu/cpuX/topology/thread_siblings: 3) /sys/devices/system/cpu/cpuX/topology/book_id:
the book ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
4) /sys/devices/system/cpu/cpuX/topology/thread_siblings:
internel kernel map of cpuX's hardware threads within the same internel kernel map of cpuX's hardware threads within the same
core as cpuX core as cpuX
4) /sys/devices/system/cpu/cpuX/topology/core_siblings: 5) /sys/devices/system/cpu/cpuX/topology/core_siblings:
internal kernel map of cpuX's hardware threads within the same internal kernel map of cpuX's hardware threads within the same
physical_package_id. physical_package_id.
6) /sys/devices/system/cpu/cpuX/topology/book_siblings:
internal kernel map of cpuX's hardware threads within the same
book_id.
To implement it in an architecture-neutral way, a new source file, To implement it in an architecture-neutral way, a new source file,
drivers/base/topology.c, is to export the 4 attributes. drivers/base/topology.c, is to export the 4 or 6 attributes. The two book
related sysfs files will only be created if CONFIG_SCHED_BOOK is selected.
For an architecture to support this feature, it must define some of For an architecture to support this feature, it must define some of
these macros in include/asm-XXX/topology.h: these macros in include/asm-XXX/topology.h:
#define topology_physical_package_id(cpu) #define topology_physical_package_id(cpu)
#define topology_core_id(cpu) #define topology_core_id(cpu)
#define topology_book_id(cpu)
#define topology_thread_cpumask(cpu) #define topology_thread_cpumask(cpu)
#define topology_core_cpumask(cpu) #define topology_core_cpumask(cpu)
#define topology_book_cpumask(cpu)
The type of **_id is int. The type of **_id is int.
The type of siblings is (const) struct cpumask *. The type of siblings is (const) struct cpumask *.
...@@ -45,6 +59,9 @@ not defined by include/asm-XXX/topology.h: ...@@ -45,6 +59,9 @@ not defined by include/asm-XXX/topology.h:
3) thread_siblings: just the given CPU 3) thread_siblings: just the given CPU
4) core_siblings: just the given CPU 4) core_siblings: just the given CPU
For architectures that don't support books (CONFIG_SCHED_BOOK) there are no
default definitions for topology_book_id() and topology_book_cpumask().
Additionally, CPU topology information is provided under Additionally, CPU topology information is provided under
/sys/devices/system/cpu and includes these files. The internal /sys/devices/system/cpu and includes these files. The internal
source for the output is in brackets ("[]"). source for the output is in brackets ("[]").
......
Documentation/devices.txt
浏览文件 @ 7d7a48b7
...@@ -239,6 +239,7 @@ Your cooperation is appreciated. ...@@ -239,6 +239,7 @@ Your cooperation is appreciated.
0 = /dev/tty Current TTY device 0 = /dev/tty Current TTY device
1 = /dev/console System console 1 = /dev/console System console
2 = /dev/ptmx PTY master multiplex 2 = /dev/ptmx PTY master multiplex
3 = /dev/ttyprintk User messages via printk TTY device
64 = /dev/cua0 Callout device for ttyS0 64 = /dev/cua0 Callout device for ttyS0
... ...
255 = /dev/cua191 Callout device for ttyS191 255 = /dev/cua191 Callout device for ttyS191
...@@ -2553,7 +2554,10 @@ Your cooperation is appreciated. ...@@ -2553,7 +2554,10 @@ Your cooperation is appreciated.
175 = /dev/usb/legousbtower15 16th USB Legotower device 175 = /dev/usb/legousbtower15 16th USB Legotower device
176 = /dev/usb/usbtmc1 First USB TMC device 176 = /dev/usb/usbtmc1 First USB TMC device
... ...
192 = /dev/usb/usbtmc16 16th USB TMC device 191 = /dev/usb/usbtmc16 16th USB TMC device
192 = /dev/usb/yurex1 First USB Yurex device
...
209 = /dev/usb/yurex16 16th USB Yurex device
240 = /dev/usb/dabusb0 First daubusb device 240 = /dev/usb/dabusb0 First daubusb device
... ...
243 = /dev/usb/dabusb3 Fourth dabusb device 243 = /dev/usb/dabusb3 Fourth dabusb device
......
Documentation/dynamic-debug-howto.txt
浏览文件 @ 7d7a48b7
...@@ -24,7 +24,7 @@ Dynamic debug has even more useful features: ...@@ -24,7 +24,7 @@ Dynamic debug has even more useful features:
read to display the complete list of known debug statements, to help guide you read to display the complete list of known debug statements, to help guide you
Controlling dynamic debug Behaviour Controlling dynamic debug Behaviour
=============================== ===================================
The behaviour of pr_debug()/dev_debug()s are controlled via writing to a The behaviour of pr_debug()/dev_debug()s are controlled via writing to a
control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs
...@@ -212,6 +212,26 @@ Note the regexp ^[-+=][scp]+$ matches a flags specification. ...@@ -212,6 +212,26 @@ Note the regexp ^[-+=][scp]+$ matches a flags specification.
Note also that there is no convenient syntax to remove all Note also that there is no convenient syntax to remove all
the flags at once, you need to use "-psc". the flags at once, you need to use "-psc".
Debug messages during boot process
==================================
To be able to activate debug messages during the boot process,
even before userspace and debugfs exists, use the boot parameter:
ddebug_query="QUERY"
QUERY follows the syntax described above, but must not exceed 1023
characters. The enablement of debug messages is done as an arch_initcall.
Thus you can enable debug messages in all code processed after this
arch_initcall via this boot parameter.
On an x86 system for example ACPI enablement is a subsys_initcall and
ddebug_query="file ec.c +p"
will show early Embedded Controller transactions during ACPI setup if
your machine (typically a laptop) has an Embedded Controller.
PCI (or other devices) initialization also is a hot candidate for using
this boot parameter for debugging purposes.
Examples Examples
======== ========
......
Documentation/feature-removal-schedule.txt
浏览文件 @ 7d7a48b7
...@@ -386,34 +386,6 @@ Who: Tejun Heo <tj@kernel.org> ...@@ -386,34 +386,6 @@ Who: Tejun Heo <tj@kernel.org>
---------------------------- ----------------------------
What: Support for VMware's guest paravirtuliazation technique [VMI] will be
dropped.
When: 2.6.37 or earlier.
Why: With the recent innovations in CPU hardware acceleration technologies
from Intel and AMD, VMware ran a few experiments to compare these
techniques to guest paravirtualization technique on VMware's platform.
These hardware assisted virtualization techniques have outperformed the
performance benefits provided by VMI in most of the workloads. VMware
expects that these hardware features will be ubiquitous in a couple of
years, as a result, VMware has started a phased retirement of this
feature from the hypervisor. We will be removing this feature from the
Kernel too. Right now we are targeting 2.6.37 but can retire earlier if
technical reasons (read opportunity to remove major chunk of pvops)
arise.
Please note that VMI has always been an optimization and non-VMI kernels
still work fine on VMware's platform.
Latest versions of VMware's product which support VMI are,
Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence
releases for these products will continue supporting VMI.
For more details about VMI retirement take a look at this,
http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
Who: Alok N Kataria <akataria@vmware.com>
----------------------------
What: Support for lcd_switch and display_get in asus-laptop driver What: Support for lcd_switch and display_get in asus-laptop driver
When: March 2010 When: March 2010
Why: These two features use non-standard interfaces. There are the Why: These two features use non-standard interfaces. There are the
...@@ -564,3 +536,12 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> ...@@ -564,3 +536,12 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---------------------------- ----------------------------
What: iwlwifi disable_hw_scan module parameters
When: 2.6.40
Why: Hareware scan is the prefer method for iwlwifi devices for
scanning operation. Remove software scan support for all the
iwlwifi devices.
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
----------------------------
Documentation/filesystems/ocfs2.txt
浏览文件 @ 7d7a48b7
...@@ -87,3 +87,10 @@ dir_resv_level= (*) By default, directory reservations will scale with file ...@@ -87,3 +87,10 @@ dir_resv_level= (*) By default, directory reservations will scale with file
reservations - users should rarely need to change this reservations - users should rarely need to change this
value. If allocation reservations are turned off, this value. If allocation reservations are turned off, this
option will have no effect. option will have no effect.
coherency=full (*) Disallow concurrent O_DIRECT writes, cluster inode
lock will be taken to force other nodes drop cache,
therefore full cluster coherency is guaranteed even
for O_DIRECT writes.
coherency=buffered Allow concurrent O_DIRECT writes without EX lock among
nodes, which gains high performance at risk of getting
stale data on other nodes.
Documentation/input/ntrig.txt 0 → 100644
浏览文件 @ 7d7a48b7
N-Trig touchscreen Driver
-------------------------
Copyright (c) 2008-2010 Rafi Rubin <rafi@seas.upenn.edu>
Copyright (c) 2009-2010 Stephane Chatty
This driver provides support for N-Trig pen and multi-touch sensors. Single
and multi-touch events are translated to the appropriate protocols for
the hid and input systems. Pen events are sufficiently hid compliant and
are left to the hid core. The driver also provides additional filtering
and utility functions accessible with sysfs and module parameters.
This driver has been reported to work properly with multiple N-Trig devices
attached.
Parameters
----------
Note: values set at load time are global and will apply to all applicable
devices. Adjusting parameters with sysfs will override the load time values,
but only for that one device.
The following parameters are used to configure filters to reduce noise:
activate_slack number of fingers to ignore before processing events
activation_height size threshold to activate immediately
activation_width
min_height size threshold bellow which fingers are ignored
min_width both to decide activation and during activity
deactivate_slack the number of "no contact" frames to ignore before
propagating the end of activity events
When the last finger is removed from the device, it sends a number of empty
frames. By holding off on deactivation for a few frames we can tolerate false
erroneous disconnects, where the sensor may mistakenly not detect a finger that
is still present. Thus deactivate_slack addresses problems where a users might
see breaks in lines during drawing, or drop an object during a long drag.
Additional sysfs items
----------------------
These nodes just provide easy access to the ranges reported by the device.
sensor_logical_height the range for positions reported during activity
sensor_logical_width
sensor_physical_height internal ranges not used for normal events but
sensor_physical_width useful for tuning
All N-Trig devices with product id of 1 report events in the ranges of
X: 0-9600
Y: 0-7200
However not all of these devices have the same physical dimensions. Most
seem to be 12" sensors (Dell Latitude XT and XT2 and the HP TX2), and
at least one model (Dell Studio 17) has a 17" sensor. The ratio of physical
to logical sizes is used to adjust the size based filter parameters.
Filtering
---------
With the release of the early multi-touch firmwares it became increasingly
obvious that these sensors were prone to erroneous events. Users reported
seeing both inappropriately dropped contact and ghosts, contacts reported
where no finger was actually touching the screen.
Deactivation slack helps prevent dropped contact for single touch use, but does
not address the problem of dropping one of more contacts while other contacts
are still active. Drops in the multi-touch context require additional
processing and should be handled in tandem with tacking.
As observed ghost contacts are similar to actual use of the sensor, but they
seem to have different profiles. Ghost activity typically shows up as small
short lived touches. As such, I assume that the longer the continuous stream
of events the more likely those events are from a real contact, and that the
larger the size of each contact the more likely it is real. Balancing the
goals of preventing ghosts and accepting real events quickly (to minimize
user observable latency), the filter accumulates confidence for incoming
events until it hits thresholds and begins propagating. In the interest in
minimizing stored state as well as the cost of operations to make a decision,
I've kept that decision simple.
Time is measured in terms of the number of fingers reported, not frames since
the probability of multiple simultaneous ghosts is expected to drop off
dramatically with increasing numbers. Rather than accumulate weight as a
function of size, I just use it as a binary threshold. A sufficiently large
contact immediately overrides the waiting period and leads to activation.
Setting the activation size thresholds to large values will result in deciding
primarily on activation slack. If you see longer lived ghosts, turning up the
activation slack while reducing the size thresholds may suffice to eliminate
the ghosts while keeping the screen quite responsive to firm taps.
Contacts continue to be filtered with min_height and min_width even after
the initial activation filter is satisfied. The intent is to provide
a mechanism for filtering out ghosts in the form of an extra finger while
you actually are using the screen. In practice this sort of ghost has
been far less problematic or relatively rare and I've left the defaults
set to 0 for both parameters, effectively turning off that filter.
I don't know what the optimal values are for these filters. If the defaults
don't work for you, please play with the parameters. If you do find other
values more comfortable, I would appreciate feedback.
The calibration of these devices does drift over time. If ghosts or contact
dropping worsen and interfere with the normal usage of your device, try
recalibrating it.
Calibration
-----------
The N-Trig windows tools provide calibration and testing routines. Also an
unofficial unsupported set of user space tools including a calibrator is
available at:
http://code.launchpad.net/~rafi-seas/+junk/ntrig_calib
Tracking
--------
As of yet, all tested N-Trig firmwares do not track fingers. When multiple
contacts are active they seem to be sorted primarily by Y position.
Documentation/kernel-parameters.txt
浏览文件 @ 7d7a48b7
...@@ -43,10 +43,11 @@ parameter is applicable: ...@@ -43,10 +43,11 @@ parameter is applicable:
AVR32 AVR32 architecture is enabled. AVR32 AVR32 architecture is enabled.
AX25 Appropriate AX.25 support is enabled. AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled. BLACKFIN Blackfin architecture is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
EFI EFI Partitioning (GPT) is enabled EFI EFI Partitioning (GPT) is enabled
EIDE EIDE/ATAPI support is enabled. EIDE EIDE/ATAPI support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
FB The frame buffer device is enabled. FB The frame buffer device is enabled.
GCOV GCOV profiling is enabled. GCOV GCOV profiling is enabled.
HW Appropriate hardware is enabled. HW Appropriate hardware is enabled.
...@@ -455,7 +456,7 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -455,7 +456,7 @@ and is between 256 and 4096 characters. It is defined in the file
[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2, [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
pxa_timer,timer3,32k_counter,timer0_1 pxa_timer,timer3,32k_counter,timer0_1
[AVR32] avr32 [AVR32] avr32
[X86-32] pit,hpet,tsc,vmi-timer; [X86-32] pit,hpet,tsc;
scx200_hrt on Geode; cyclone on IBM x440 scx200_hrt on Geode; cyclone on IBM x440
[MIPS] MIPS [MIPS] MIPS
[PARISC] cr16 [PARISC] cr16
...@@ -570,6 +571,10 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -570,6 +571,10 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <port#>,<type> Format: <port#>,<type>
See also Documentation/input/joystick-parport.txt See also Documentation/input/joystick-parport.txt
ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See Documentation/dynamic-debug-howto.txt for
details.
debug [KNL] Enable kernel debugging (events log level). debug [KNL] Enable kernel debugging (events log level).
debug_locks_verbose= debug_locks_verbose=
...@@ -1126,9 +1131,13 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1126,9 +1131,13 @@ and is between 256 and 4096 characters. It is defined in the file
kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging. kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging.
Default is 1 (enabled) Default is 1 (enabled)
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit
KVM MMU at runtime.
Default is 0 (off) Default is 0 (off)
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
Default is 1 (enabled)
kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU) kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU)
for all guests. for all guests.
Default is 1 (enabled) if in 64bit or 32bit-PAE mode Default is 1 (enabled) if in 64bit or 32bit-PAE mode
...@@ -1693,6 +1702,8 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1693,6 +1702,8 @@ and is between 256 and 4096 characters. It is defined in the file
nojitter [IA64] Disables jitter checking for ITC timers. nojitter [IA64] Disables jitter checking for ITC timers.
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic [X86-32,APIC] Do not enable or use the local APIC.
nolapic_timer [X86-32,APIC] Do not use the local APIC timer. nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
...@@ -1713,7 +1724,7 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1713,7 +1724,7 @@ and is between 256 and 4096 characters. It is defined in the file
norandmaps Don't use address space randomization. Equivalent to norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space echo 0 > /proc/sys/kernel/randomize_va_space
noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops
noreplace-smp [X86-32,SMP] Don't replace SMP instructions noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives with UP alternatives
...@@ -2153,6 +2164,11 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -2153,6 +2164,11 @@ and is between 256 and 4096 characters. It is defined in the file
Reserves a hole at the top of the kernel virtual Reserves a hole at the top of the kernel virtual
address space. address space.
reservelow= [X86]
Format: nn[K]
Set the amount of memory to reserve for BIOS at
the bottom of the address space.
reset_devices [KNL] Force drivers to reset the underlying device reset_devices [KNL] Force drivers to reset the underlying device
during initialization. during initialization.
...@@ -2165,6 +2181,11 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -2165,6 +2181,11 @@ and is between 256 and 4096 characters. It is defined in the file
in <PAGE_SIZE> units (needed only for swap files). in <PAGE_SIZE> units (needed only for swap files).
See Documentation/power/swsusp-and-swap-files.txt See Documentation/power/swsusp-and-swap-files.txt
hibernate= [HIBERNATION]
noresume Don't check if there's a hibernation image
present during boot.
nocompress Don't compress/decompress hibernation images.
retain_initrd [RAM] Keep initrd memory after extraction retain_initrd [RAM] Keep initrd memory after extraction
rhash_entries= [KNL,NET] rhash_entries= [KNL,NET]
...@@ -2360,6 +2381,15 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -2360,6 +2381,15 @@ and is between 256 and 4096 characters. It is defined in the file
switches= [HW,M68k] switches= [HW,M68k]
sysfs.deprecated=0|1 [KNL]
Enable/disable old style sysfs layout for old udev
on older distributions. When this option is enabled
very new udev will not work anymore. When this option
is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
in older udev will not work anymore.
Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
the kernel configuration.
sysrq_always_enabled sysrq_always_enabled
[KNL] [KNL]
Ignore sysrq setting - this boot parameter will Ignore sysrq setting - this boot parameter will
...@@ -2435,6 +2465,10 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -2435,6 +2465,10 @@ and is between 256 and 4096 characters. It is defined in the file
disables clocksource verification at runtime. disables clocksource verification at runtime.
Used to enable high-resolution timer mode on older Used to enable high-resolution timer mode on older
hardware, and in virtualized environment. hardware, and in virtualized environment.
[x86] noirqtime: Do not use TSC to do irq accounting.
Used to run time disable IRQ_TIME_ACCOUNTING on any
platforms where RDTSC is slow and this accounting
can add overhead.
turbografx.map[2|3]= [HW,JOY] turbografx.map[2|3]= [HW,JOY]
TurboGraFX parallel port interface TurboGraFX parallel port interface
......
Documentation/kprobes.txt
浏览文件 @ 7d7a48b7
...@@ -542,9 +542,11 @@ Kprobes does not use mutexes or allocate memory except during ...@@ -542,9 +542,11 @@ Kprobes does not use mutexes or allocate memory except during
registration and unregistration. registration and unregistration.
Probe handlers are run with preemption disabled. Depending on the Probe handlers are run with preemption disabled. Depending on the
architecture, handlers may also run with interrupts disabled. In any architecture and optimization state, handlers may also run with
case, your handler should not yield the CPU (e.g., by attempting to interrupts disabled (e.g., kretprobe handlers and optimized kprobe
acquire a semaphore). handlers run without interrupt disabled on x86/x86-64). In any case,
your handler should not yield the CPU (e.g., by attempting to acquire
a semaphore).
Since a return probe is implemented by replacing the return Since a return probe is implemented by replacing the return
address with the trampoline's address, stack backtraces and calls address with the trampoline's address, stack backtraces and calls
......
Documentation/kvm/api.txt
浏览文件 @ 7d7a48b7
...@@ -320,13 +320,13 @@ struct kvm_translation { ...@@ -320,13 +320,13 @@ struct kvm_translation {
4.15 KVM_INTERRUPT 4.15 KVM_INTERRUPT
Capability: basic Capability: basic
Architectures: x86 Architectures: x86, ppc
Type: vcpu ioctl Type: vcpu ioctl
Parameters: struct kvm_interrupt (in) Parameters: struct kvm_interrupt (in)
Returns: 0 on success, -1 on error Returns: 0 on success, -1 on error
Queues a hardware interrupt vector to be injected. This is only Queues a hardware interrupt vector to be injected. This is only
useful if in-kernel local APIC is not used. useful if in-kernel local APIC or equivalent is not used.
/* for KVM_INTERRUPT */ /* for KVM_INTERRUPT */
struct kvm_interrupt { struct kvm_interrupt {
...@@ -334,8 +334,37 @@ struct kvm_interrupt { ...@@ -334,8 +334,37 @@ struct kvm_interrupt {
__u32 irq; __u32 irq;
}; };
X86:
Note 'irq' is an interrupt vector, not an interrupt pin or line. Note 'irq' is an interrupt vector, not an interrupt pin or line.
PPC:
Queues an external interrupt to be injected. This ioctl is overleaded
with 3 different irq values:
a) KVM_INTERRUPT_SET
This injects an edge type external interrupt into the guest once it's ready
to receive interrupts. When injected, the interrupt is done.
b) KVM_INTERRUPT_UNSET
This unsets any pending interrupt.
Only available with KVM_CAP_PPC_UNSET_IRQ.
c) KVM_INTERRUPT_SET_LEVEL
This injects a level type external interrupt into the guest context. The
interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET
is triggered.
Only available with KVM_CAP_PPC_IRQ_LEVEL.
Note that any value for 'irq' other than the ones stated above is invalid
and incurs unexpected behavior.
4.16 KVM_DEBUG_GUEST 4.16 KVM_DEBUG_GUEST
Capability: basic Capability: basic
...@@ -1013,8 +1042,9 @@ number is just right, the 'nent' field is adjusted to the number of valid ...@@ -1013,8 +1042,9 @@ number is just right, the 'nent' field is adjusted to the number of valid
entries in the 'entries' array, which is then filled. entries in the 'entries' array, which is then filled.
The entries returned are the host cpuid as returned by the cpuid instruction, The entries returned are the host cpuid as returned by the cpuid instruction,
with unknown or unsupported features masked out. The fields in each entry with unknown or unsupported features masked out. Some features (for example,
are defined as follows: x2apic), may not be present in the host cpu, but are exposed by kvm if it can
emulate them efficiently. The fields in each entry are defined as follows:
function: the eax value used to obtain the entry function: the eax value used to obtain the entry
index: the ecx value used to obtain the entry (for entries that are index: the ecx value used to obtain the entry (for entries that are
...@@ -1032,6 +1062,29 @@ are defined as follows: ...@@ -1032,6 +1062,29 @@ are defined as follows:
eax, ebx, ecx, edx: the values returned by the cpuid instruction for eax, ebx, ecx, edx: the values returned by the cpuid instruction for
this function/index combination this function/index combination
4.46 KVM_PPC_GET_PVINFO
Capability: KVM_CAP_PPC_GET_PVINFO
Architectures: ppc
Type: vm ioctl
Parameters: struct kvm_ppc_pvinfo (out)
Returns: 0 on success, !0 on error
struct kvm_ppc_pvinfo {
__u32 flags;
__u32 hcall[4];
__u8 pad[108];
};
This ioctl fetches PV specific information that need to be passed to the guest
using the device tree or other means from vm context.
For now the only implemented piece of information distributed here is an array
of 4 instructions that make up a hypercall.
If any additional field gets added to this structure later on, a bit for that
additional piece of information will be set in the flags bitmap.
5. The kvm_run structure 5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by Application code obtains a pointer to the kvm_run structure by
......
Documentation/kvm/ppc-pv.txt 0 → 100644
浏览文件 @ 7d7a48b7
The PPC KVM paravirtual interface
=================================
The basic execution principle by which KVM on PowerPC works is to run all kernel
space code in PR=1 which is user space. This way we trap all privileged
instructions and can emulate them accordingly.
Unfortunately that is also the downfall. There are quite some privileged
instructions that needlessly return us to the hypervisor even though they
could be handled differently.
This is what the PPC PV interface helps with. It takes privileged instructions
and transforms them into unprivileged ones with some help from the hypervisor.
This cuts down virtualization costs by about 50% on some of my benchmarks.
The code for that interface can be found in arch/powerpc/kernel/kvm*
Querying for existence
======================
To find out if we're running on KVM or not, we leverage the device tree. When
Linux is running on KVM, a node /hypervisor exists. That node contains a
compatible property with the value "linux,kvm".
Once you determined you're running under a PV capable KVM, you can now use
hypercalls as described below.
KVM hypercalls
==============
Inside the device tree's /hypervisor node there's a property called
'hypercall-instructions'. This property contains at most 4 opcodes that make
up the hypercall. To call a hypercall, just call these instructions.
The parameters are as follows:
Register IN OUT
r0 - volatile
r3 1st parameter Return code
r4 2nd parameter 1st output value
r5 3rd parameter 2nd output value
r6 4th parameter 3rd output value
r7 5th parameter 4th output value
r8 6th parameter 5th output value
r9 7th parameter 6th output value
r10 8th parameter 7th output value
r11 hypercall number 8th output value
r12 - volatile
Hypercall definitions are shared in generic code, so the same hypercall numbers
apply for x86 and powerpc alike with the exception that each KVM hypercall
also needs to be ORed with the KVM vendor code which is (42 << 16).
Return codes can be as follows:
Code Meaning
0 Success
12 Hypercall not implemented
<0 Error
The magic page
==============
To enable communication between the hypervisor and guest there is a new shared
page that contains parts of supervisor visible register state. The guest can
map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE.
With this hypercall issued the guest always gets the magic page mapped at the
desired location in effective and physical address space. For now, we always
map the page to -4096. This way we can access it using absolute load and store
functions. The following instruction reads the first field of the magic page:
ld rX, -4096(0)
The interface is designed to be extensible should there be need later to add
additional registers to the magic page. If you add fields to the magic page,
also define a new hypercall feature to indicate that the host can give you more
registers. Only if the host supports the additional features, make use of them.
The magic page has the following layout as described in
arch/powerpc/include/asm/kvm_para.h:
struct kvm_vcpu_arch_shared {
__u64 scratch1;
__u64 scratch2;
__u64 scratch3;
__u64 critical; /* Guest may not get interrupts if == r1 */
__u64 sprg0;
__u64 sprg1;
__u64 sprg2;
__u64 sprg3;
__u64 srr0;
__u64 srr1;
__u64 dar;
__u64 msr;
__u32 dsisr;
__u32 int_pending; /* Tells the guest if we have an interrupt */
};
Additions to the page must only occur at the end. Struct fields are always 32
or 64 bit aligned, depending on them being 32 or 64 bit wide respectively.
Magic page features
===================
When mapping the magic page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE,
a second return value is passed to the guest. This second return value contains
a bitmap of available features inside the magic page.
The following enhancements to the magic page are currently available:
KVM_MAGIC_FEAT_SR Maps SR registers r/w in the magic page
For enhanced features in the magic page, please check for the existence of the
feature before using them!
MSR bits
========
The MSR contains bits that require hypervisor intervention and bits that do
not require direct hypervisor intervention because they only get interpreted
when entering the guest or don't have any impact on the hypervisor's behavior.
The following bits are safe to be set inside the guest:
MSR_EE
MSR_RI
MSR_CR
MSR_ME
If any other bit changes in the MSR, please still use mtmsr(d).
Patched instructions
====================
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
respectively on 32 bit systems with an added offset of 4 to accomodate for big
endianness.
The following is a list of mapping the Linux kernel performs when running as
guest. Implementing any of those mappings is optional, as the instruction traps
also act on the shared page. So calling privileged instructions still works as
before.
From To
==== ==
mfmsr rX ld rX, magic_page->msr
mfsprg rX, 0 ld rX, magic_page->sprg0
mfsprg rX, 1 ld rX, magic_page->sprg1
mfsprg rX, 2 ld rX, magic_page->sprg2
mfsprg rX, 3 ld rX, magic_page->sprg3
mfsrr0 rX ld rX, magic_page->srr0
mfsrr1 rX ld rX, magic_page->srr1
mfdar rX ld rX, magic_page->dar
mfdsisr rX lwz rX, magic_page->dsisr
mtmsr rX std rX, magic_page->msr
mtsprg 0, rX std rX, magic_page->sprg0
mtsprg 1, rX std rX, magic_page->sprg1
mtsprg 2, rX std rX, magic_page->sprg2
mtsprg 3, rX std rX, magic_page->sprg3
mtsrr0 rX std rX, magic_page->srr0
mtsrr1 rX std rX, magic_page->srr1
mtdar rX std rX, magic_page->dar
mtdsisr rX stw rX, magic_page->dsisr
tlbsync nop
mtmsrd rX, 0 b <special mtmsr section>
mtmsr rX b <special mtmsr section>
mtmsrd rX, 1 b <special mtmsrd section>
[Book3S only]
mtsrin rX, rY b <special mtsrin section>
[BookE only]
wrteei [0|1] b <special wrteei section>
Some instructions require more logic to determine what's going on than a load
or store instruction can deliver. To enable patching of those, we keep some
RAM around where we can live translate instructions to. What happens is the
following:
1) copy emulation code to memory
2) patch that code to fit the emulated instruction
3) patch that code to return to the original pc + 4
4) patch the original instruction to branch to the new code
That way we can inject an arbitrary amount of code as replacement for a single
instruction. This allows us to check for pending interrupts when setting EE=1
for example.
Documentation/kvm/timekeeping.txt 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
Documentation/lguest/lguest.c
浏览文件 @ 7d7a48b7
...@@ -1639,15 +1639,6 @@ static void blk_request(struct virtqueue *vq) ...@@ -1639,15 +1639,6 @@ static void blk_request(struct virtqueue *vq)
*/ */
off = out->sector * 512; off = out->sector * 512;
/*
* The block device implements "barriers", where the Guest indicates
* that it wants all previous writes to occur before this write. We
* don't have a way of asking our kernel to do a barrier, so we just
* synchronize all the data in the file. Pretty poor, no?
*/
if (out->type & VIRTIO_BLK_T_BARRIER)
fdatasync(vblk->fd);
/* /*
* In general the virtio block driver is allowed to try SCSI commands. * In general the virtio block driver is allowed to try SCSI commands.
* It'd be nice if we supported eject, for example, but we don't. * It'd be nice if we supported eject, for example, but we don't.
...@@ -1680,6 +1671,13 @@ static void blk_request(struct virtqueue *vq) ...@@ -1680,6 +1671,13 @@ static void blk_request(struct virtqueue *vq)
/* Die, bad Guest, die. */ /* Die, bad Guest, die. */
errx(1, "Write past end %llu+%u", off, ret); errx(1, "Write past end %llu+%u", off, ret);
} }
wlen = sizeof(*in);
*in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
} else if (out->type & VIRTIO_BLK_T_FLUSH) {
/* Flush */
ret = fdatasync(vblk->fd);
verbose("FLUSH fdatasync: %i\n", ret);
wlen = sizeof(*in); wlen = sizeof(*in);
*in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR); *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
} else { } else {
...@@ -1703,15 +1701,6 @@ static void blk_request(struct virtqueue *vq) ...@@ -1703,15 +1701,6 @@ static void blk_request(struct virtqueue *vq)
} }
} }
/*
* OK, so we noted that it was pretty poor to use an fdatasync as a
* barrier. But Christoph Hellwig points out that we need a sync
* *afterwards* as well: "Barriers specify no reordering to the front
* or the back." And Jens Axboe confirmed it, so here we are:
*/
if (out->type & VIRTIO_BLK_T_BARRIER)
fdatasync(vblk->fd);
/* Finished that request. */ /* Finished that request. */
add_used(vq, head, wlen); add_used(vq, head, wlen);
} }
...@@ -1736,8 +1725,8 @@ static void setup_block_file(const char *filename) ...@@ -1736,8 +1725,8 @@ static void setup_block_file(const char *filename)
vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE); vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE);
vblk->len = lseek64(vblk->fd, 0, SEEK_END); vblk->len = lseek64(vblk->fd, 0, SEEK_END);
/* We support barriers. */ /* We support FLUSH. */
add_feature(dev, VIRTIO_BLK_F_BARRIER); add_feature(dev, VIRTIO_BLK_F_FLUSH);
/* Tell Guest how many sectors this device has. */ /* Tell Guest how many sectors this device has. */
conf.capacity = cpu_to_le64(vblk->len / 512); conf.capacity = cpu_to_le64(vblk->len / 512);
......
Documentation/networking/bonding.txt
浏览文件 @ 7d7a48b7
...@@ -765,6 +765,14 @@ xmit_hash_policy ...@@ -765,6 +765,14 @@ xmit_hash_policy
does not exist, and the layer2 policy is the only policy. The does not exist, and the layer2 policy is the only policy. The
layer2+3 value was added for bonding version 3.2.2. layer2+3 value was added for bonding version 3.2.2.
resend_igmp
Specifies the number of IGMP membership reports to be issued after
a failover event. One membership report is issued immediately after
the failover, subsequent packets are sent in each 200ms interval.
The valid range is 0 - 255; the default value is 1. This option
was added for bonding version 3.7.0.
3. Configuring Bonding Devices 3. Configuring Bonding Devices
============================== ==============================
......
Documentation/networking/can.txt
浏览文件 @ 7d7a48b7
...@@ -22,6 +22,7 @@ This file contains ...@@ -22,6 +22,7 @@ This file contains
4.1.2 RAW socket option CAN_RAW_ERR_FILTER 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
4.1.3 RAW socket option CAN_RAW_LOOPBACK 4.1.3 RAW socket option CAN_RAW_LOOPBACK
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
4.1.5 RAW socket returned message flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET) 4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM) 4.4 unconnected transport protocols (SOCK_DGRAM)
...@@ -471,6 +472,17 @@ solution for a couple of reasons: ...@@ -471,6 +472,17 @@ solution for a couple of reasons:
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
&recv_own_msgs, sizeof(recv_own_msgs)); &recv_own_msgs, sizeof(recv_own_msgs));
4.1.5 RAW socket returned message flags
When using recvmsg() call, the msg->msg_flags may contain following flags:
MSG_DONTROUTE: set when the received frame was created on the local host.
MSG_CONFIRM: set when the frame was sent via the socket it is received on.
This flag can be interpreted as a 'transmission confirmation' when the
CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET) 4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM) 4.4 unconnected transport protocols (SOCK_DGRAM)
......
Documentation/networking/dccp.txt
浏览文件 @ 7d7a48b7
DCCP protocol DCCP protocol
============ =============
Contents Contents
======== ========
- Introduction - Introduction
- Missing features - Missing features
- Socket options - Socket options
- Sysctl variables
- IOCTLs
- Other tunables
- Notes - Notes
Introduction Introduction
============ ============
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
oriented protocol designed to solve issues present in UDP and TCP, particularly oriented protocol designed to solve issues present in UDP and TCP, particularly
for real-time and multimedia (streaming) traffic. for real-time and multimedia (streaming) traffic.
...@@ -29,9 +31,9 @@ It has a base protocol and pluggable congestion control IDs (CCIDs). ...@@ -29,9 +31,9 @@ It has a base protocol and pluggable congestion control IDs (CCIDs).
DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
is at http://www.ietf.org/html.charters/dccp-charter.html is at http://www.ietf.org/html.charters/dccp-charter.html
Missing features Missing features
================ ================
The Linux DCCP implementation does not currently support all the features that are The Linux DCCP implementation does not currently support all the features that are
specified in RFCs 4340...42. specified in RFCs 4340...42.
...@@ -45,7 +47,6 @@ http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree ...@@ -45,7 +47,6 @@ http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree
Socket options Socket options
============== ==============
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
the socket will fall back to 0 (which means that no meaningful service code the socket will fall back to 0 (which means that no meaningful service code
...@@ -112,6 +113,7 @@ DCCP_SOCKOPT_CCID_TX_INFO ...@@ -112,6 +113,7 @@ DCCP_SOCKOPT_CCID_TX_INFO
On unidirectional connections it is useful to close the unused half-connection On unidirectional connections it is useful to close the unused half-connection
via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs. via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs.
Sysctl variables Sysctl variables
================ ================
Several DCCP default parameters can be managed by the following sysctls Several DCCP default parameters can be managed by the following sysctls
...@@ -155,15 +157,30 @@ sync_ratelimit = 125 ms ...@@ -155,15 +157,30 @@ sync_ratelimit = 125 ms
sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
of this parameter is milliseconds; a value of 0 disables rate-limiting. of this parameter is milliseconds; a value of 0 disables rate-limiting.
IOCTLS IOCTLS
====== ======
FIONREAD FIONREAD
Works as in udp(7): returns in the `int' argument pointer the size of Works as in udp(7): returns in the `int' argument pointer the size of
the next pending datagram in bytes, or 0 when no datagram is pending. the next pending datagram in bytes, or 0 when no datagram is pending.
Other tunables
==============
Per-route rto_min support
CCID-2 supports the RTAX_RTO_MIN per-route setting for the minimum value
of the RTO timer. This setting can be modified via the 'rto_min' option
of iproute2; for example:
> ip route change 10.0.0.0/24 rto_min 250j dev wlan0
> ip route add 10.0.0.254/32 rto_min 800j dev wlan0
> ip route show dev wlan0
CCID-3 also supports the rto_min setting: it is used to define the lower
bound for the expiry of the nofeedback timer. This can be useful on LANs
with very low RTTs (e.g., loopback, Gbit ethernet).
Notes Notes
===== =====
DCCP does not travel through NAT successfully at present on many boxes. This is DCCP does not travel through NAT successfully at present on many boxes. This is
because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT
support for DCCP has been added. support for DCCP has been added.
Documentation/networking/ip-sysctl.txt
浏览文件 @ 7d7a48b7
...@@ -1014,6 +1014,12 @@ conf/interface/*: ...@@ -1014,6 +1014,12 @@ conf/interface/*:
accept_ra - BOOLEAN accept_ra - BOOLEAN
Accept Router Advertisements; autoconfigure using them. Accept Router Advertisements; autoconfigure using them.
Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.
Functional default: enabled if local forwarding is disabled. Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled. disabled if local forwarding is enabled.
...@@ -1075,7 +1081,12 @@ forwarding - BOOLEAN ...@@ -1075,7 +1081,12 @@ forwarding - BOOLEAN
Note: It is recommended to have the same setting on all Note: It is recommended to have the same setting on all
interfaces; mixed router/host scenarios are rather uncommon. interfaces; mixed router/host scenarios are rather uncommon.
FALSE: Possible values are:
0 Forwarding disabled
1 Forwarding enabled
2 Forwarding enabled (Hybrid Mode)
FALSE (0):
By default, Host behaviour is assumed. This means: By default, Host behaviour is assumed. This means:
...@@ -1085,18 +1096,24 @@ forwarding - BOOLEAN ...@@ -1085,18 +1096,24 @@ forwarding - BOOLEAN
Advertisements (and do autoconfiguration). Advertisements (and do autoconfiguration).
4. If accept_redirects is TRUE (default), accept Redirects. 4. If accept_redirects is TRUE (default), accept Redirects.
TRUE: TRUE (1):
If local forwarding is enabled, Router behaviour is assumed. If local forwarding is enabled, Router behaviour is assumed.
This means exactly the reverse from the above: This means exactly the reverse from the above:
1. IsRouter flag is set in Neighbour Advertisements. 1. IsRouter flag is set in Neighbour Advertisements.
2. Router Solicitations are not sent. 2. Router Solicitations are not sent.
3. Router Advertisements are ignored. 3. Router Advertisements are ignored unless accept_ra is 2.
4. Redirects are ignored. 4. Redirects are ignored.
Default: FALSE if global forwarding is disabled (default), TRUE (2):
otherwise TRUE.
Hybrid mode. Same behaviour as TRUE, except for:
2. Router Solicitations are being sent when necessary.
Default: 0 (disabled) if global forwarding is disabled (default),
otherwise 1 (enabled).
hop_limit - INTEGER hop_limit - INTEGER
Default Hop Limit to set. Default Hop Limit to set.
......
Documentation/networking/phonet.txt
浏览文件 @ 7d7a48b7
...@@ -112,6 +112,22 @@ However, connect() and getpeername() are not supported, as they did ...@@ -112,6 +112,22 @@ However, connect() and getpeername() are not supported, as they did
not seem useful with Phonet usages (could be added easily). not seem useful with Phonet usages (could be added easily).
Resource subscription
---------------------
A Phonet datagram socket can be subscribed to any number of 8-bits
Phonet resources, as follow:
uint32_t res = 0xXX;
ioctl(fd, SIOCPNADDRESOURCE, &res);
Subscription is similarly cancelled using the SIOCPNDELRESOURCE I/O
control request, or when the socket is closed.
Note that no more than one socket can be subcribed to any given
resource at a time. If not, ioctl() will return EBUSY.
Phonet Pipe protocol Phonet Pipe protocol
-------------------- --------------------
...@@ -166,6 +182,46 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level: ...@@ -166,6 +182,46 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level:
or zero if encapsulation is off. or zero if encapsulation is off.
Phonet Pipe-controller Implementation
-------------------------------------
Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig
option. It is useful when communicating with those Nokia Modems which do not
implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson
U8500 platform.
The implementation is based on the Data Connection Establishment Sequence
depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf'
document.
It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection
between itself and a remote pipe-end point (e.g. modem).
The implementation adds socket options at SOL_PNPIPE level:
PNPIPE_PIPE_HANDLE
It accepts an integer argument for setting value of pipe handle.
PNPIPE_ENABLE accepts one integer value (int). If set to zero, the pipe
is disabled. If the value is non-zero, the pipe is enabled. If the pipe
is not (yet) connected, ENOTCONN is error is returned.
The implementation also adds socket 'connect'. On calling the 'connect', pipe
will be created between the source socket and the destination, and the pipe
state will be set to PIPE_DISABLED.
After a pipe has been created and enabled successfully, the Pipe data can be
exchanged between the host-pep and remote-pep (modem).
User-space would typically follow below sequence with Pipe controller:-
-socket
-bind
-setsockopt for PNPIPE_PIPE_HANDLE
-connect
-setsockopt for PNPIPE_ENCAP_IP
-setsockopt for PNPIPE_ENABLE
Authors Authors
------- -------
......
Documentation/networking/timestamping.txt
浏览文件 @ 7d7a48b7
...@@ -172,15 +172,19 @@ struct skb_shared_hwtstamps { ...@@ -172,15 +172,19 @@ struct skb_shared_hwtstamps {
}; };
Time stamps for outgoing packets are to be generated as follows: Time stamps for outgoing packets are to be generated as follows:
- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero. - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
If yes, then the driver is expected to do hardware time stamping. is set no-zero. If yes, then the driver is expected to do hardware time
stamping.
- If this is possible for the skb and requested, then declare - If this is possible for the skb and requested, then declare
that the driver is doing the time stamping by setting the field that the driver is doing the time stamping by setting the flag
skb_tx(skb)->in_progress non-zero. You might want to keep a pointer SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
to the associated skb for the next step and not free the skb. A driver
not supporting hardware time stamping doesn't do that. A driver must skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
never touch sk_buff::tstamp! It is used to store software generated
time stamps by the network subsystem. You might want to keep a pointer to the associated skb for the next step
and not free the skb. A driver not supporting hardware time stamping doesn't
do that. A driver must never touch sk_buff::tstamp! It is used to store
software generated time stamps by the network subsystem.
- As soon as the driver has sent the packet and/or obtained a - As soon as the driver has sent the packet and/or obtained a
hardware time stamp for it, it passes the time stamp back by hardware time stamp for it, it passes the time stamp back by
calling skb_hwtstamp_tx() with the original skb, the raw calling skb_hwtstamp_tx() with the original skb, the raw
...@@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows: ...@@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows:
this would occur at a later time in the processing pipeline than other this would occur at a later time in the processing pipeline than other
software time stamping and therefore could lead to unexpected deltas software time stamping and therefore could lead to unexpected deltas
between time stamps. between time stamps.
- If the driver did not call set skb_tx(skb)->in_progress, then - If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then
dev_hard_start_xmit() checks whether software time stamping dev_hard_start_xmit() checks whether software time stamping
is wanted as fallback and potentially generates the time stamp. is wanted as fallback and potentially generates the time stamp.
Documentation/pcmcia/driver-changes.txt
浏览文件 @ 7d7a48b7
This file details changes in 2.6 which affect PCMCIA card driver authors: This file details changes in 2.6 which affect PCMCIA card driver authors:
* pcmcia_loop_config() and autoconfiguration (as of 2.6.36)
If struct pcmcia_device *p_dev->config_flags is set accordingly,
pcmcia_loop_config() now sets up certain configuration values
automatically, though the driver may still override the settings
in the callback function. The following autoconfiguration options
are provided at the moment:
CONF_AUTO_CHECK_VCC : check for matching Vcc
CONF_AUTO_SET_VPP : set Vpp
CONF_AUTO_AUDIO : auto-enable audio line, if required
CONF_AUTO_SET_IO : set ioport resources (->resource[0,1])
CONF_AUTO_SET_IOMEM : set first iomem resource (->resource[2])
* pcmcia_request_configuration -> pcmcia_enable_device (as of 2.6.36)
pcmcia_request_configuration() got renamed to pcmcia_enable_device(),
as it mirrors pcmcia_disable_device(). Configuration settings are now
stored in struct pcmcia_device, e.g. in the fields config_flags,
config_index, config_base, vpp.
* pcmcia_request_window changes (as of 2.6.36)
Instead of win_req_t, drivers are now requested to fill out
struct pcmcia_device *p_dev->resource[2,3,4,5] for up to four ioport
ranges. After a call to pcmcia_request_window(), the regions found there
are reserved and may be used immediately -- until pcmcia_release_window()
is called.
* pcmcia_request_io changes (as of 2.6.36) * pcmcia_request_io changes (as of 2.6.36)
Instead of io_req_t, drivers are now requested to fill out Instead of io_req_t, drivers are now requested to fill out
struct pcmcia_device *p_dev->resource[0,1] for up to two ioport struct pcmcia_device *p_dev->resource[0,1] for up to two ioport
......
Documentation/power/00-INDEX
浏览文件 @ 7d7a48b7
...@@ -14,6 +14,8 @@ interface.txt ...@@ -14,6 +14,8 @@ interface.txt
- Power management user interface in /sys/power - Power management user interface in /sys/power
notifiers.txt notifiers.txt
- Registering suspend notifiers in device drivers - Registering suspend notifiers in device drivers
opp.txt
- Operating Performance Point library
pci.txt pci.txt
- How the PCI Subsystem Does Power Management - How the PCI Subsystem Does Power Management
pm_qos_interface.txt pm_qos_interface.txt
......
Documentation/power/interface.txt
浏览文件 @ 7d7a48b7
...@@ -57,7 +57,7 @@ smallest image possible. In particular, if "0" is written to this file, the ...@@ -57,7 +57,7 @@ smallest image possible. In particular, if "0" is written to this file, the
suspend image will be as small as possible. suspend image will be as small as possible.
Reading from this file will display the current image size limit, which Reading from this file will display the current image size limit, which
is set to 500 MB by default. is set to 2/5 of available RAM by default.
/sys/power/pm_trace controls the code which saves the last PM event point in /sys/power/pm_trace controls the code which saves the last PM event point in
the RTC across reboots, so that you can debug a machine that just hangs the RTC across reboots, so that you can debug a machine that just hangs
......
Documentation/power/opp.txt 0 → 100644
浏览文件 @ 7d7a48b7
*=============*
* OPP Library *
*=============*
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
Contents
--------
1. Introduction
2. Initial OPP List Registration
3. OPP Search Functions
4. OPP Availability Control Functions
5. OPP Data Retrieval Functions
6. Cpufreq Table Generation
7. Data Structures
1. Introduction
===============
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
In an operational system executing varied use cases, not all modules in the SoC
need to function at their highest performing frequency all the time. To
facilitate this, sub-modules in a SoC are grouped into domains, allowing some
domains to run at lower voltage and frequency while other domains are loaded
more. The set of discrete tuples consisting of frequency and voltage pairs that
the device will support per domain are called Operating Performance Points or
OPPs.
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
is located in include/linux/opp.h. OPP library can be enabled by enabling
CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
Typical usage of the OPP library is as follows:
(users) -> registers a set of default OPPs -> (library)
SoC framework -> modifies on required cases certain OPPs -> OPP layer
-> queries to search/retrieve information ->
OPP layer expects each domain to be represented by a unique device pointer. SoC
framework registers a set of initial OPPs per device with the OPP layer. This
list is expected to be an optimally small number typically around 5 per device.
This initial list contains a set of OPPs that the framework expects to be safely
enabled by default in the system.
Note on OPP Availability:
------------------------
As the system proceeds to operate, SoC framework may choose to make certain
OPPs available or not available on each device based on various external
factors. Example usage: Thermal management or other exceptional situations where
SoC framework might choose to disable a higher frequency OPP to safely continue
operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in it's implementation. The following
operational functions operate only on available opps:
opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
and opp_init_cpufreq_table
opp_find_freq_exact is meant to be used to find the opp pointer which can then
be used for opp_enable/disable functions to make an opp available as required.
WARNING: Users of OPP library should refresh their availability count using
get_opp_count if opp_enable/disable functions are invoked for a device, the
exact mechanism to trigger these or the notification mechanism to other
dependent subsystems such as cpufreq are left to the discretion of the SoC
specific framework which uses the OPP library. Similar care needs to be taken
care to refresh the cpufreq table in cases of these operations.
WARNING on OPP List locking mechanism:
-------------------------------------------------
OPP library uses RCU for exclusivity. RCU allows the query functions to operate
in multiple contexts and this synchronization mechanism is optimal for a read
intensive operations on data structure as the OPP library caters to.
To ensure that the data retrieved are sane, the users such as SoC framework
should ensure that the section of code operating on OPP queries are locked
using RCU read locks. The opp_find_freq_{exact,ceil,floor},
opp_get_{voltage, freq, opp_count} fall into this category.
opp_{add,enable,disable} are updaters which use mutex and implement it's own
RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
mutex to implment RCU updater strategy. These functions should *NOT* be called
under RCU locks and other contexts that prevent blocking functions in RCU or
mutex operations from working.
2. Initial OPP List Registration
================================
The SoC implementation calls opp_add function iteratively to add OPPs per
device. It is expected that the SoC framework will register the OPP entries
optimally- typical numbers range to be less than 5. The list generated by
registering the OPPs is maintained by OPP library throughout the device
operation. The SoC framework can subsequently control the availability of the
OPPs dynamically using the opp_enable / disable functions.
opp_add - Add a new OPP for a specific domain represented by the device pointer.
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of it's availability can be done
with the opp_enable/disable functions. OPP library internally stores
and manages this information in the opp struct. This function may be
used by SoC framework to define a optimal list as per the demands of
SoC usage environment.
WARNING: Do not use this function in interrupt context.
Example:
soc_pm_init()
{
/* Do things */
r = opp_add(mpu_dev, 1000000, 900000);
if (!r) {
pr_err("%s: unable to register mpu opp(%d)\n", r);
goto no_cpufreq;
}
/* Do cpufreq things */
no_cpufreq:
/* Do remaining things */
}
3. OPP Search Functions
=======================
High level framework such as cpufreq operates on frequencies. To map the
frequency back to the corresponding OPP, OPP library provides handy functions
to search the OPP list that OPP library internally manages. These search
functions return the matching pointer representing the opp if a match is
found, else returns error. These errors are expected to be handled by standard
error checks such as IS_ERR() and appropriate actions taken by the caller.
opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
availability. This function is especially useful to enable an OPP which
is not available by default.
Example: In a case when SoC framework detects a situation where a
higher frequency could be made available, it can use this function to
find the OPP prior to call the opp_enable to actually make it available.
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, false);
rcu_read_unlock();
/* dont operate on the pointer.. just do a sanity check.. */
if (IS_ERR(opp)) {
pr_err("frequency not disabled!\n");
/* trigger appropriate actions.. */
} else {
opp_enable(dev,1000000000);
}
NOTE: This is the only search function that operates on OPPs which are
not available.
opp_find_freq_floor - Search for an available OPP which is *at most* the
provided frequency. This function is useful while searching for a lesser
match OR operating on OPP information in the order of decreasing
frequency.
Example: To find the highest opp for a device:
freq = ULONG_MAX;
rcu_read_lock();
opp_find_freq_floor(dev, &freq);
rcu_read_unlock();
opp_find_freq_ceil - Search for an available OPP which is *at least* the
provided frequency. This function is useful while searching for a
higher match OR operating on OPP information in the order of increasing
frequency.
Example 1: To find the lowest opp for a device:
freq = 0;
rcu_read_lock();
opp_find_freq_ceil(dev, &freq);
rcu_read_unlock();
Example 2: A simplified implementation of a SoC cpufreq_driver->target:
soc_cpufreq_target(..)
{
/* Do stuff like policy checks etc. */
/* Find the best frequency match for the req */
rcu_read_lock();
opp = opp_find_freq_ceil(dev, &freq);
rcu_read_unlock();
if (!IS_ERR(opp))
soc_switch_to_freq_voltage(freq);
else
/* do something when we cant satisfy the req */
/* do other stuff */
}
4. OPP Availability Control Functions
=====================================
A default OPP list registered with the OPP library may not cater to all possible
situation. The OPP library provides a set of functions to modify the
availability of a OPP within the OPP list. This allows SoC frameworks to have
fine grained dynamic control of which sets of OPPs are operationally available.
These functions are intended to *temporarily* remove an OPP in conditions such
as thermal considerations (e.g. don't use OPPx until the temperature drops).
WARNING: Do not use these functions in interrupt context.
opp_enable - Make a OPP available for operation.
Example: Lets say that 1GHz OPP is to be made available only if the
SoC temperature is lower than a certain threshold. The SoC framework
implementation might choose to do something as follows:
if (cur_temp < temp_low_thresh) {
/* Enable 1GHz if it was disabled */
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, false);
rcu_read_unlock();
/* just error check */
if (!IS_ERR(opp))
ret = opp_enable(dev, 1000000000);
else
goto try_something_else;
}
opp_disable - Make an OPP to be not available for operation
Example: Lets say that 1GHz OPP is to be disabled if the temperature
exceeds a threshold value. The SoC framework implementation might
choose to do something as follows:
if (cur_temp > temp_high_thresh) {
/* Disable 1GHz if it was enabled */
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, true);
rcu_read_unlock();
/* just error check */
if (!IS_ERR(opp))
ret = opp_disable(dev, 1000000000);
else
goto try_something_else;
}
5. OPP Data Retrieval Functions
===============================
Since OPP library abstracts away the OPP information, a set of functions to pull
information from the OPP structure is necessary. Once an OPP pointer is
retrieved using the search functions, the following functions can be used by SoC
framework to retrieve the information represented inside the OPP layer.
opp_get_voltage - Retrieve the voltage represented by the opp pointer.
Example: At a cpufreq transition to a different frequency, SoC
framework requires to set the voltage represented by the OPP using
the regulator framework to the Power Management chip providing the
voltage.
soc_switch_to_freq_voltage(freq)
{
/* do things */
rcu_read_lock();
opp = opp_find_freq_ceil(dev, &freq);
v = opp_get_voltage(opp);
rcu_read_unlock();
if (v)
regulator_set_voltage(.., v);
/* do other things */
}
opp_get_freq - Retrieve the freq represented by the opp pointer.
Example: Lets say the SoC framework uses a couple of helper functions
we could pass opp pointers instead of doing additional parameters to
handle quiet a bit of data parameters.
soc_cpufreq_target(..)
{
/* do things.. */
max_freq = ULONG_MAX;
rcu_read_lock();
max_opp = opp_find_freq_floor(dev,&max_freq);
requested_opp = opp_find_freq_ceil(dev,&freq);
if (!IS_ERR(max_opp) && !IS_ERR(requested_opp))
r = soc_test_validity(max_opp, requested_opp);
rcu_read_unlock();
/* do other things */
}
soc_test_validity(..)
{
if(opp_get_voltage(max_opp) < opp_get_voltage(requested_opp))
return -EINVAL;
if(opp_get_freq(max_opp) < opp_get_freq(requested_opp))
return -EINVAL;
/* do things.. */
}
opp_get_opp_count - Retrieve the number of available opps for a device
Example: Lets say a co-processor in the SoC needs to know the available
frequencies in a table, the main processor can notify as following:
soc_notify_coproc_available_frequencies()
{
/* Do things */
rcu_read_lock();
num_available = opp_get_opp_count(dev);
speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL);
/* populate the table in increasing order */
freq = 0;
while (!IS_ERR(opp = opp_find_freq_ceil(dev, &freq))) {
speeds[i] = freq;
freq++;
i++;
}
rcu_read_unlock();
soc_notify_coproc(AVAILABLE_FREQs, speeds, num_available);
/* Do other things */
}
6. Cpufreq Table Generation
===========================
opp_init_cpufreq_table - cpufreq framework typically is initialized with
cpufreq_frequency_table_cpuinfo which is provided with the list of
frequencies that are available for operation. This function provides
a ready to use conversion routine to translate the OPP layer's internal
information about the available frequencies into a format readily
providable to cpufreq.
WARNING: Do not use this function in interrupt context.
Example:
soc_pm_init()
{
/* Do things */
r = opp_init_cpufreq_table(dev, &freq_table);
if (!r)
cpufreq_frequency_table_cpuinfo(policy, freq_table);
/* Do other things */
}
NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
addition to CONFIG_PM as power management feature is required to
dynamically scale voltage and frequency in a system.
7. Data Structures
==================
Typically an SoC contains multiple voltage domains which are variable. Each
domain is represented by a device pointer. The relationship to OPP can be
represented as follows:
SoC
|- device 1
| |- opp 1 (availability, freq, voltage)
| |- opp 2 ..
... ...
| `- opp n ..
|- device 2
...
`- device m
OPP library maintains a internal list that the SoC framework populates and
accessed by various functions as described above. However, the structures
representing the actual OPPs and domains are internal to the OPP library itself
to allow for suitable abstraction reusable across systems.
struct opp - The internal data structure of OPP library which is used to
represent an OPP. In addition to the freq, voltage, availability
information, it also contains internal book keeping information required
for the OPP library to operate on. Pointer to this structure is
provided back to the users such as SoC framework to be used as a
identifier for OPP in the interactions with OPP layer.
WARNING: The struct opp pointer should not be parsed or modified by the
users. The defaults of for an instance is populated by opp_add, but the
availability of the OPP can be modified by opp_enable/disable functions.
struct device - This is used to identify a domain to the OPP layer. The
nature of the device and it's implementation is left to the user of
OPP library such as the SoC framework.
Overall, in a simplistic view, the data structure operations is represented as
following:
Initialization / modification:
+-----+ /- opp_enable
opp_add --> | opp | <-------
| +-----+ \- opp_disable
\-------> domain_info(device)
Search functions:
/-- opp_find_freq_ceil ---\ +-----+
domain_info<---- opp_find_freq_exact -----> | opp |
\-- opp_find_freq_floor ---/ +-----+
Retrieval functions:
+-----+ /- opp_get_voltage
| opp | <---
+-----+ \- opp_get_freq
domain_info <- opp_get_opp_count
Documentation/power/runtime_pm.txt
浏览文件 @ 7d7a48b7
Run-time Power Management Framework for I/O Devices Run-time Power Management Framework for I/O Devices
(C) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. (C) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
(C) 2010 Alan Stern <stern@rowland.harvard.edu>
1. Introduction 1. Introduction
...@@ -157,7 +158,8 @@ rules: ...@@ -157,7 +158,8 @@ rules:
to execute it, the other callbacks will not be executed for the same device. to execute it, the other callbacks will not be executed for the same device.
* A request to execute ->runtime_resume() will cancel any pending or * A request to execute ->runtime_resume() will cancel any pending or
scheduled requests to execute the other callbacks for the same device. scheduled requests to execute the other callbacks for the same device,
except for scheduled autosuspends.
3. Run-time PM Device Fields 3. Run-time PM Device Fields
...@@ -165,7 +167,7 @@ The following device run-time PM fields are present in 'struct dev_pm_info', as ...@@ -165,7 +167,7 @@ The following device run-time PM fields are present in 'struct dev_pm_info', as
defined in include/linux/pm.h: defined in include/linux/pm.h:
struct timer_list suspend_timer; struct timer_list suspend_timer;
- timer used for scheduling (delayed) suspend request - timer used for scheduling (delayed) suspend and autosuspend requests
unsigned long timer_expires; unsigned long timer_expires;
- timer expiration time, in jiffies (if this is different from zero, the - timer expiration time, in jiffies (if this is different from zero, the
...@@ -230,6 +232,28 @@ defined in include/linux/pm.h: ...@@ -230,6 +232,28 @@ defined in include/linux/pm.h:
interface; it may only be modified with the help of the pm_runtime_allow() interface; it may only be modified with the help of the pm_runtime_allow()
and pm_runtime_forbid() helper functions and pm_runtime_forbid() helper functions
unsigned int no_callbacks;
- indicates that the device does not use the run-time PM callbacks (see
Section 8); it may be modified only by the pm_runtime_no_callbacks()
helper function
unsigned int use_autosuspend;
- indicates that the device's driver supports delayed autosuspend (see
Section 9); it may be modified only by the
pm_runtime{_dont}_use_autosuspend() helper functions
unsigned int timer_autosuspends;
- indicates that the PM core should attempt to carry out an autosuspend
when the timer expires rather than a normal suspend
int autosuspend_delay;
- the delay time (in milliseconds) to be used for autosuspend
unsigned long last_busy;
- the time (in jiffies) when the pm_runtime_mark_last_busy() helper
function was last called for this device; used in calculating inactivity
periods for autosuspend
All of the above fields are members of the 'power' member of 'struct device'. All of the above fields are members of the 'power' member of 'struct device'.
4. Run-time PM Device Helper Functions 4. Run-time PM Device Helper Functions
...@@ -255,6 +279,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: ...@@ -255,6 +279,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
to suspend the device again in future to suspend the device again in future
int pm_runtime_autosuspend(struct device *dev);
- same as pm_runtime_suspend() except that the autosuspend delay is taken
into account; if pm_runtime_autosuspend_expiration() says the delay has
not yet expired then an autosuspend is scheduled for the appropriate time
and 0 is returned
int pm_runtime_resume(struct device *dev); int pm_runtime_resume(struct device *dev);
- execute the subsystem-level resume callback for the device; returns 0 on - execute the subsystem-level resume callback for the device; returns 0 on
success, 1 if the device's run-time PM status was already 'active' or success, 1 if the device's run-time PM status was already 'active' or
...@@ -267,6 +297,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: ...@@ -267,6 +297,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
device (the request is represented by a work item in pm_wq); returns 0 on device (the request is represented by a work item in pm_wq); returns 0 on
success or error code if the request has not been queued up success or error code if the request has not been queued up
int pm_request_autosuspend(struct device *dev);
- schedule the execution of the subsystem-level suspend callback for the
device when the autosuspend delay has expired; if the delay has already
expired then the work item is queued up immediately
int pm_schedule_suspend(struct device *dev, unsigned int delay); int pm_schedule_suspend(struct device *dev, unsigned int delay);
- schedule the execution of the subsystem-level suspend callback for the - schedule the execution of the subsystem-level suspend callback for the
device in future, where 'delay' is the time to wait before queuing up a device in future, where 'delay' is the time to wait before queuing up a
...@@ -298,12 +333,20 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: ...@@ -298,12 +333,20 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
- decrement the device's usage counter - decrement the device's usage counter
int pm_runtime_put(struct device *dev); int pm_runtime_put(struct device *dev);
- decrement the device's usage counter, run pm_request_idle(dev) and return - decrement the device's usage counter; if the result is 0 then run
its result pm_request_idle(dev) and return its result
int pm_runtime_put_autosuspend(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
pm_request_autosuspend(dev) and return its result
int pm_runtime_put_sync(struct device *dev); int pm_runtime_put_sync(struct device *dev);
- decrement the device's usage counter, run pm_runtime_idle(dev) and return - decrement the device's usage counter; if the result is 0 then run
its result pm_runtime_idle(dev) and return its result
int pm_runtime_put_sync_autosuspend(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
pm_runtime_autosuspend(dev) and return its result
void pm_runtime_enable(struct device *dev); void pm_runtime_enable(struct device *dev);
- enable the run-time PM helper functions to run the device bus type's - enable the run-time PM helper functions to run the device bus type's
...@@ -349,19 +392,51 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: ...@@ -349,19 +392,51 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
counter (used by the /sys/devices/.../power/control interface to counter (used by the /sys/devices/.../power/control interface to
effectively prevent the device from being power managed at run time) effectively prevent the device from being power managed at run time)
void pm_runtime_no_callbacks(struct device *dev);
- set the power.no_callbacks flag for the device and remove the run-time
PM attributes from /sys/devices/.../power (or prevent them from being
added when the device is registered)
void pm_runtime_mark_last_busy(struct device *dev);
- set the power.last_busy field to the current time
void pm_runtime_use_autosuspend(struct device *dev);
- set the power.use_autosuspend flag, enabling autosuspend delays
void pm_runtime_dont_use_autosuspend(struct device *dev);
- clear the power.use_autosuspend flag, disabling autosuspend delays
void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
- set the power.autosuspend_delay value to 'delay' (expressed in
milliseconds); if 'delay' is negative then run-time suspends are
prevented
unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
- calculate the time when the current autosuspend delay period will expire,
based on power.last_busy and power.autosuspend_delay; if the delay time
is 1000 ms or larger then the expiration time is rounded up to the
nearest second; returns 0 if the delay period has already expired or
power.use_autosuspend isn't set, otherwise returns the expiration time
in jiffies
It is safe to execute the following helper functions from interrupt context: It is safe to execute the following helper functions from interrupt context:
pm_request_idle() pm_request_idle()
pm_request_autosuspend()
pm_schedule_suspend() pm_schedule_suspend()
pm_request_resume() pm_request_resume()
pm_runtime_get_noresume() pm_runtime_get_noresume()
pm_runtime_get() pm_runtime_get()
pm_runtime_put_noidle() pm_runtime_put_noidle()
pm_runtime_put() pm_runtime_put()
pm_runtime_put_autosuspend()
pm_runtime_enable()
pm_suspend_ignore_children() pm_suspend_ignore_children()
pm_runtime_set_active() pm_runtime_set_active()
pm_runtime_set_suspended() pm_runtime_set_suspended()
pm_runtime_enable() pm_runtime_suspended()
pm_runtime_mark_last_busy()
pm_runtime_autosuspend_expiration()
5. Run-time PM Initialization, Device Probing and Removal 5. Run-time PM Initialization, Device Probing and Removal
...@@ -524,3 +599,141 @@ poweroff and run-time suspend callback, and similarly for system resume, thaw, ...@@ -524,3 +599,141 @@ poweroff and run-time suspend callback, and similarly for system resume, thaw,
restore, and run-time resume, can achieve this with the help of the restore, and run-time resume, can achieve this with the help of the
UNIVERSAL_DEV_PM_OPS macro defined in include/linux/pm.h (possibly setting its UNIVERSAL_DEV_PM_OPS macro defined in include/linux/pm.h (possibly setting its
last argument to NULL). last argument to NULL).
8. "No-Callback" Devices
Some "devices" are only logical sub-devices of their parent and cannot be
power-managed on their own. (The prototype example is a USB interface. Entire
USB devices can go into low-power mode or send wake-up requests, but neither is
possible for individual interfaces.) The drivers for these devices have no
need of run-time PM callbacks; if the callbacks did exist, ->runtime_suspend()
and ->runtime_resume() would always return 0 without doing anything else and
->runtime_idle() would always call pm_runtime_suspend().
Subsystems can tell the PM core about these devices by calling
pm_runtime_no_callbacks(). This should be done after the device structure is
initialized and before it is registered (although after device registration is
also okay). The routine will set the device's power.no_callbacks flag and
prevent the non-debugging run-time PM sysfs attributes from being created.
When power.no_callbacks is set, the PM core will not invoke the
->runtime_idle(), ->runtime_suspend(), or ->runtime_resume() callbacks.
Instead it will assume that suspends and resumes always succeed and that idle
devices should be suspended.
As a consequence, the PM core will never directly inform the device's subsystem
or driver about run-time power changes. Instead, the driver for the device's
parent must take responsibility for telling the device's driver when the
parent's power state changes.
9. Autosuspend, or automatically-delayed suspends
Changing a device's power state isn't free; it requires both time and energy.
A device should be put in a low-power state only when there's some reason to
think it will remain in that state for a substantial time. A common heuristic
says that a device which hasn't been used for a while is liable to remain
unused; following this advice, drivers should not allow devices to be suspended
at run-time until they have been inactive for some minimum period. Even when
the heuristic ends up being non-optimal, it will still prevent devices from
"bouncing" too rapidly between low-power and full-power states.
The term "autosuspend" is an historical remnant. It doesn't mean that the
device is automatically suspended (the subsystem or driver still has to call
the appropriate PM routines); rather it means that run-time suspends will
automatically be delayed until the desired period of inactivity has elapsed.
Inactivity is determined based on the power.last_busy field. Drivers should
call pm_runtime_mark_last_busy() to update this field after carrying out I/O,
typically just before calling pm_runtime_put_autosuspend(). The desired length
of the inactivity period is a matter of policy. Subsystems can set this length
initially by calling pm_runtime_set_autosuspend_delay(), but after device
registration the length should be controlled by user space, using the
/sys/devices/.../power/autosuspend_delay_ms attribute.
In order to use autosuspend, subsystems or drivers must call
pm_runtime_use_autosuspend() (preferably before registering the device), and
thereafter they should use the various *_autosuspend() helper functions instead
of the non-autosuspend counterparts:
Instead of: pm_runtime_suspend use: pm_runtime_autosuspend;
Instead of: pm_schedule_suspend use: pm_request_autosuspend;
Instead of: pm_runtime_put use: pm_runtime_put_autosuspend;
Instead of: pm_runtime_put_sync use: pm_runtime_put_sync_autosuspend.
Drivers may also continue to use the non-autosuspend helper functions; they
will behave normally, not taking the autosuspend delay into account.
Similarly, if the power.use_autosuspend field isn't set then the autosuspend
helper functions will behave just like the non-autosuspend counterparts.
The implementation is well suited for asynchronous use in interrupt contexts.
However such use inevitably involves races, because the PM core can't
synchronize ->runtime_suspend() callbacks with the arrival of I/O requests.
This synchronization must be handled by the driver, using its private lock.
Here is a schematic pseudo-code example:
foo_read_or_write(struct foo_priv *foo, void *data)
{
lock(&foo->private_lock);
add_request_to_io_queue(foo, data);
if (foo->num_pending_requests++ == 0)
pm_runtime_get(&foo->dev);
if (!foo->is_suspended)
foo_process_next_request(foo);
unlock(&foo->private_lock);
}
foo_io_completion(struct foo_priv *foo, void *req)
{
lock(&foo->private_lock);
if (--foo->num_pending_requests == 0) {
pm_runtime_mark_last_busy(&foo->dev);
pm_runtime_put_autosuspend(&foo->dev);
} else {
foo_process_next_request(foo);
}
unlock(&foo->private_lock);
/* Send req result back to the user ... */
}
int foo_runtime_suspend(struct device *dev)
{
struct foo_priv foo = container_of(dev, ...);
int ret = 0;
lock(&foo->private_lock);
if (foo->num_pending_requests > 0) {
ret = -EBUSY;
} else {
/* ... suspend the device ... */
foo->is_suspended = 1;
}
unlock(&foo->private_lock);
return ret;
}
int foo_runtime_resume(struct device *dev)
{
struct foo_priv foo = container_of(dev, ...);
lock(&foo->private_lock);
/* ... resume the device ... */
foo->is_suspended = 0;
pm_runtime_mark_last_busy(&foo->dev);
if (foo->num_pending_requests > 0)
foo_process_requests(foo);
unlock(&foo->private_lock);
return 0;
}
The important point is that after foo_io_completion() asks for an autosuspend,
the foo_runtime_suspend() callback may race with foo_read_or_write().
Therefore foo_runtime_suspend() has to check whether there are any pending I/O
requests (while holding the private lock) before allowing the suspend to
proceed.
In addition, the power.autosuspend_delay field can be changed by user space at
any time. If a driver cares about this, it can call
pm_runtime_autosuspend_expiration() from within the ->runtime_suspend()
callback while holding its private lock. If the function returns a nonzero
value then the delay has not yet expired and the callback should return
-EAGAIN.
Documentation/power/s2ram.txt
浏览文件 @ 7d7a48b7
...@@ -49,6 +49,13 @@ machine that doesn't boot) is: ...@@ -49,6 +49,13 @@ machine that doesn't boot) is:
device (lspci and /sys/devices/pci* is your friend), and see if you can device (lspci and /sys/devices/pci* is your friend), and see if you can
fix it, disable it, or trace into its resume function. fix it, disable it, or trace into its resume function.
If no device matches the hash (or any matches appear to be false positives),
the culprit may be a device from a loadable kernel module that is not loaded
until after the hash is checked. You can check the hash against the current
devices again after more modules are loaded using sysfs:
cat /sys/power/pm_trace_dev_match
For example, the above happens to be the VGA device on my EVO, which I For example, the above happens to be the VGA device on my EVO, which I
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
that "radeonfb" simply cannot resume that device - it tries to set the that "radeonfb" simply cannot resume that device - it tries to set the
......
Documentation/power/swsusp.txt
浏览文件 @ 7d7a48b7
...@@ -66,7 +66,8 @@ swsusp saves the state of the machine into active swaps and then reboots or ...@@ -66,7 +66,8 @@ swsusp saves the state of the machine into active swaps and then reboots or
powerdowns. You must explicitly specify the swap partition to resume from with powerdowns. You must explicitly specify the swap partition to resume from with
``resume='' kernel option. If signature is found it loads and restores saved ``resume='' kernel option. If signature is found it loads and restores saved
state. If the option ``noresume'' is specified as a boot parameter, it skips state. If the option ``noresume'' is specified as a boot parameter, it skips
the resuming. the resuming. If the option ``hibernate=nocompress'' is specified as a boot
parameter, it saves hibernation image without compression.
In the meantime while the system is suspended you should not add/remove any In the meantime while the system is suspended you should not add/remove any
of the hardware, write to the filesystems, etc. of the hardware, write to the filesystems, etc.
......
Documentation/powerpc/dts-bindings/fsl/spi.txt
浏览文件 @ 7d7a48b7
* SPI (Serial Peripheral Interface) * SPI (Serial Peripheral Interface)
Required properties: Required properties:
- cell-index : SPI controller index. - cell-index : QE SPI subblock index.
0: QE subblock SPI1
1: QE subblock SPI2
- compatible : should be "fsl,spi". - compatible : should be "fsl,spi".
- mode : the SPI operation mode, it can be "cpu" or "cpu-qe". - mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
- reg : Offset and length of the register set for the device - reg : Offset and length of the register set for the device
...@@ -29,3 +31,23 @@ Example: ...@@ -29,3 +31,23 @@ Example:
gpios = <&gpio 18 1 // device reg=<0> gpios = <&gpio 18 1 // device reg=<0>
&gpio 19 1>; // device reg=<1> &gpio 19 1>; // device reg=<1>
}; };
* eSPI (Enhanced Serial Peripheral Interface)
Required properties:
- compatible : should be "fsl,mpc8536-espi".
- reg : Offset and length of the register set for the device.
- interrupts : should contain eSPI interrupt, the device has one interrupt.
- fsl,espi-num-chipselects : the number of the chipselect signals.
Example:
spi@110000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8536-espi";
reg = <0x110000 0x1000>;
interrupts = <53 0x2>;
interrupt-parent = <&mpic>;
fsl,espi-num-chipselects = <4>;
};
Documentation/powerpc/dts-bindings/fsl/usb.txt
浏览文件 @ 7d7a48b7
...@@ -8,6 +8,7 @@ and additions : ...@@ -8,6 +8,7 @@ and additions :
Required properties : Required properties :
- compatible : Should be "fsl-usb2-mph" for multi port host USB - compatible : Should be "fsl-usb2-mph" for multi port host USB
controllers, or "fsl-usb2-dr" for dual role USB controllers controllers, or "fsl-usb2-dr" for dual role USB controllers
or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of - phy_type : For multi port host USB controllers, should be one of
"ulpi", or "serial". For dual role USB controllers, should be "ulpi", or "serial". For dual role USB controllers, should be
one of "ulpi", "utmi", "utmi_wide", or "serial". one of "ulpi", "utmi", "utmi_wide", or "serial".
...@@ -33,6 +34,12 @@ Recommended properties : ...@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that - interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device. services interrupts for this device.
Optional properties :
- fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
port power polarity of internal PHY signal DRVVBUS is inverted.
- fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
the PWR_FAULT signal polarity is inverted.
Example multi port host USB controller device node : Example multi port host USB controller device node :
usb@22000 { usb@22000 {
compatible = "fsl-usb2-mph"; compatible = "fsl-usb2-mph";
...@@ -57,3 +64,18 @@ Example dual role USB controller device node : ...@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = "otg"; dr_mode = "otg";
phy = "ulpi"; phy = "ulpi";
}; };
Example dual role USB controller device node for MPC5121ADS:
usb@4000 {
compatible = "fsl,mpc5121-usb2-dr";
reg = <0x4000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <44 0x8>;
dr_mode = "otg";
phy_type = "utmi_wide";
fsl,invert-drvvbus;
fsl,invert-pwr-fault;
};
Documentation/scsi/st.txt
浏览文件 @ 7d7a48b7
...@@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver. ...@@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver.
The driver is currently maintained by Kai Mäkisara (email The driver is currently maintained by Kai Mäkisara (email
Kai.Makisara@kolumbus.fi) Kai.Makisara@kolumbus.fi)
Last modified: Sun Feb 24 21:59:07 2008 by kai.makisara Last modified: Sun Aug 29 18:25:47 2010 by kai.makisara
BASICS BASICS
...@@ -85,6 +85,17 @@ writing and the last operation has been a write. Two filemarks can be ...@@ -85,6 +85,17 @@ writing and the last operation has been a write. Two filemarks can be
optionally written. In both cases end of data is signified by optionally written. In both cases end of data is signified by
returning zero bytes for two consecutive reads. returning zero bytes for two consecutive reads.
Writing filemarks without the immediate bit set in the SCSI command block acts
as a synchronization point, i.e., all remaining data form the drive buffers is
written to tape before the command returns. This makes sure that write errors
are caught at that point, but this takes time. In some applications, several
consecutive files must be written fast. The MTWEOFI operation can be used to
write the filemarks without flushing the drive buffer. Writing filemark at
close() is always flushing the drive buffers. However, if the previous
operation is MTWEOFI, close() does not write a filemark. This can be used if
the program wants to close/open the tape device between files and wants to
skip waiting.
If rewind, offline, bsf, or seek is done and previous tape operation was If rewind, offline, bsf, or seek is done and previous tape operation was
write, a filemark is written before moving tape. write, a filemark is written before moving tape.
...@@ -301,6 +312,8 @@ MTBSR Space backward over count records. ...@@ -301,6 +312,8 @@ MTBSR Space backward over count records.
MTFSS Space forward over count setmarks. MTFSS Space forward over count setmarks.
MTBSS Space backward over count setmarks. MTBSS Space backward over count setmarks.
MTWEOF Write count filemarks. MTWEOF Write count filemarks.
MTWEOFI Write count filemarks with immediate bit set (i.e., does not
wait until data is on tape)
MTWSM Write count setmarks. MTWSM Write count setmarks.
MTREW Rewind tape. MTREW Rewind tape.
MTOFFL Set device off line (often rewind plus eject). MTOFFL Set device off line (often rewind plus eject).
......
Documentation/usb/proc_usb_info.txt
浏览文件 @ 7d7a48b7
/proc/bus/usb filesystem output /proc/bus/usb filesystem output
=============================== ===============================
(version 2003.05.30) (version 2010.09.13)
The usbfs filesystem for USB devices is traditionally mounted at The usbfs filesystem for USB devices is traditionally mounted at
/proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as /proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as
the /proc/bus/usb/BBB/DDD files. the /proc/bus/usb/BBB/DDD files.
In many modern systems the usbfs filsystem isn't used at all. Instead
USB device nodes are created under /dev/usb/ or someplace similar. The
"devices" file is available in debugfs, typically as
/sys/kernel/debug/usb/devices.
**NOTE**: If /proc/bus/usb appears empty, and a host controller **NOTE**: If /proc/bus/usb appears empty, and a host controller
driver has been linked, then you need to mount the driver has been linked, then you need to mount the
...@@ -106,8 +111,8 @@ Legend: ...@@ -106,8 +111,8 @@ Legend:
Topology info: Topology info:
T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=dddd MxCh=dd
| | | | | | | | |__MaxChildren | | | | | | | | |__MaxChildren
| | | | | | | |__Device Speed in Mbps | | | | | | | |__Device Speed in Mbps
| | | | | | |__DeviceNumber | | | | | | |__DeviceNumber
| | | | | |__Count of devices at this level | | | | | |__Count of devices at this level
...@@ -120,8 +125,13 @@ T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd ...@@ -120,8 +125,13 @@ T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd
Speed may be: Speed may be:
1.5 Mbit/s for low speed USB 1.5 Mbit/s for low speed USB
12 Mbit/s for full speed USB 12 Mbit/s for full speed USB
480 Mbit/s for high speed USB (added for USB 2.0) 480 Mbit/s for high speed USB (added for USB 2.0);
also used for Wireless USB, which has no fixed speed
5000 Mbit/s for SuperSpeed USB (added for USB 3.0)
For reasons lost in the mists of time, the Port number is always
too low by 1. For example, a device plugged into port 4 will
show up with "Port=03".
Bandwidth info: Bandwidth info:
B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd
...@@ -291,7 +301,7 @@ Here's an example, from a system which has a UHCI root hub, ...@@ -291,7 +301,7 @@ Here's an example, from a system which has a UHCI root hub,
an external hub connected to the root hub, and a mouse and an external hub connected to the root hub, and a mouse and
a serial converter connected to the external hub. a serial converter connected to the external hub.
T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 28/900 us ( 3%), #Int= 2, #Iso= 0 B: Alloc= 28/900 us ( 3%), #Int= 2, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00 P: Vendor=0000 ProdID=0000 Rev= 0.00
...@@ -301,21 +311,21 @@ C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA ...@@ -301,21 +311,21 @@ C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0451 ProdID=1446 Rev= 1.00 P: Vendor=0451 ProdID=1446 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms
T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04b4 ProdID=0001 Rev= 0.00 P: Vendor=04b4 ProdID=0001 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse
E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms
T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0565 ProdID=0001 Rev= 1.08 P: Vendor=0565 ProdID=0001 Rev= 1.08
S: Manufacturer=Peracom Networks, Inc. S: Manufacturer=Peracom Networks, Inc.
...@@ -330,12 +340,12 @@ E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 8ms ...@@ -330,12 +340,12 @@ E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 8ms
Selecting only the "T:" and "I:" lines from this (for example, by using Selecting only the "T:" and "I:" lines from this (for example, by using
"procusb ti"), we have: "procusb ti"), we have:
T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse
T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial
......
Documentation/vm/numa_memory_policy.txt
浏览文件 @ 7d7a48b7
...@@ -424,7 +424,7 @@ a command line tool, numactl(8), exists that allows one to: ...@@ -424,7 +424,7 @@ a command line tool, numactl(8), exists that allows one to:
+ set the shared policy for a shared memory segment via mbind(2) + set the shared policy for a shared memory segment via mbind(2)
The numactl(8) tool is packages with the run-time version of the library The numactl(8) tool is packaged with the run-time version of the library
containing the memory policy system call wrappers. Some distributions containing the memory policy system call wrappers. Some distributions
package the headers and compile-time libraries in a separate development package the headers and compile-time libraries in a separate development
package. package.
......
Documentation/workqueue.txt
浏览文件 @ 7d7a48b7
...@@ -196,11 +196,11 @@ resources, scheduled and executed. ...@@ -196,11 +196,11 @@ resources, scheduled and executed.
suspend operations. Work items on the wq are drained and no suspend operations. Work items on the wq are drained and no
new work item starts execution until thawed. new work item starts execution until thawed.
WQ_RESCUER WQ_MEM_RECLAIM
All wq which might be used in the memory reclaim paths _MUST_ All wq which might be used in the memory reclaim paths _MUST_
have this flag set. This reserves one worker exclusively for have this flag set. The wq is guaranteed to have at least one
the execution of this wq under memory pressure. execution context regardless of memory pressure.
WQ_HIGHPRI WQ_HIGHPRI
...@@ -356,11 +356,11 @@ If q1 has WQ_CPU_INTENSIVE set, ...@@ -356,11 +356,11 @@ If q1 has WQ_CPU_INTENSIVE set,
6. Guidelines 6. Guidelines
* Do not forget to use WQ_RESCUER if a wq may process work items which * Do not forget to use WQ_MEM_RECLAIM if a wq may process work items
are used during memory reclaim. Each wq with WQ_RESCUER set has one which are used during memory reclaim. Each wq with WQ_MEM_RECLAIM
rescuer thread reserved for it. If there is dependency among set has an execution context reserved for it. If there is
multiple work items used during memory reclaim, they should be dependency among multiple work items used during memory reclaim,
queued to separate wq each with WQ_RESCUER. they should be queued to separate wq each with WQ_MEM_RECLAIM.
* Unless strict ordering is required, there is no need to use ST wq. * Unless strict ordering is required, there is no need to use ST wq.
...@@ -368,12 +368,13 @@ If q1 has WQ_CPU_INTENSIVE set, ...@@ -368,12 +368,13 @@ If q1 has WQ_CPU_INTENSIVE set,
recommended. In most use cases, concurrency level usually stays recommended. In most use cases, concurrency level usually stays
well under the default limit. well under the default limit.
* A wq serves as a domain for forward progress guarantee (WQ_RESCUER), * A wq serves as a domain for forward progress guarantee
flush and work item attributes. Work items which are not involved (WQ_MEM_RECLAIM, flush and work item attributes. Work items which
in memory reclaim and don't need to be flushed as a part of a group are not involved in memory reclaim and don't need to be flushed as a
of work items, and don't require any special attribute, can use one part of a group of work items, and don't require any special
of the system wq. There is no difference in execution attribute, can use one of the system wq. There is no difference in
characteristics between using a dedicated wq and a system wq. execution characteristics between using a dedicated wq and a system
wq.
* Unless work items are expected to consume a huge amount of CPU * Unless work items are expected to consume a huge amount of CPU
cycles, using a bound wq is usually beneficial due to the increased cycles, using a bound wq is usually beneficial due to the increased
......
Documentation/x86/x86_64/kernel-stacks
浏览文件 @ 7d7a48b7
...@@ -18,9 +18,9 @@ specialized stacks contain no useful data. The main CPU stacks are: ...@@ -18,9 +18,9 @@ specialized stacks contain no useful data. The main CPU stacks are:
Used for external hardware interrupts. If this is the first external Used for external hardware interrupts. If this is the first external
hardware interrupt (i.e. not a nested hardware interrupt) then the hardware interrupt (i.e. not a nested hardware interrupt) then the
kernel switches from the current task to the interrupt stack. Like kernel switches from the current task to the interrupt stack. Like
the split thread and interrupt stacks on i386 (with CONFIG_4KSTACKS), the split thread and interrupt stacks on i386, this gives more room
this gives more room for kernel interrupt processing without having for kernel interrupt processing without having to increase the size
to increase the size of every per thread stack. of every per thread stack.
The interrupt stack is also used when processing a softirq. The interrupt stack is also used when processing a softirq.
......
Kbuild
浏览文件 @ 7d7a48b7
...@@ -53,6 +53,7 @@ targets += arch/$(SRCARCH)/kernel/asm-offsets.s ...@@ -53,6 +53,7 @@ targets += arch/$(SRCARCH)/kernel/asm-offsets.s
# Default sed regexp - multiline due to syntax constraints # Default sed regexp - multiline due to syntax constraints
define sed-y define sed-y
"/^->/{s:->#\(.*\):/* \1 */:; \ "/^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \ s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}" s:->::; p;}"
endef endef
......
MAINTAINERS
浏览文件 @ 7d7a48b7
此差异已折叠。
Makefile
浏览文件 @ 7d7a48b7
VERSION = 2 VERSION = 2
PATCHLEVEL = 6 PATCHLEVEL = 6
SUBLEVEL = 36 SUBLEVEL = 36
EXTRAVERSION = -rc7 EXTRAVERSION =
NAME = Sheep on Meth NAME = Flesh-Eating Bats with Fangs
# *DOCUMENTATION* # *DOCUMENTATION*
# To see a list of typical targets execute "make help" # To see a list of typical targets execute "make help"
...@@ -554,8 +554,15 @@ endif ...@@ -554,8 +554,15 @@ endif
ifdef CONFIG_FRAME_POINTER ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
else else
# Some targets (ARM with Thumb2, for example), can't be built with frame
# pointers. For those, we don't have FUNCTION_TRACER automatically
# select FRAME_POINTER. However, FUNCTION_TRACER adds -pg, and this is
# incompatible with -fomit-frame-pointer with current GCC, so we don't use
# -fomit-frame-pointer with FUNCTION_TRACER.
ifndef CONFIG_FUNCTION_TRACER
KBUILD_CFLAGS += -fomit-frame-pointer KBUILD_CFLAGS += -fomit-frame-pointer
endif endif
endif
ifdef CONFIG_DEBUG_INFO ifdef CONFIG_DEBUG_INFO
KBUILD_CFLAGS += -g KBUILD_CFLAGS += -g
...@@ -568,6 +575,12 @@ endif ...@@ -568,6 +575,12 @@ endif
ifdef CONFIG_FUNCTION_TRACER ifdef CONFIG_FUNCTION_TRACER
KBUILD_CFLAGS += -pg KBUILD_CFLAGS += -pg
ifdef CONFIG_DYNAMIC_FTRACE
ifdef CONFIG_HAVE_C_RECORDMCOUNT
BUILD_C_RECORDMCOUNT := y
export BUILD_C_RECORDMCOUNT
endif
endif
endif endif
# We trigger additional mismatches with less inlining # We trigger additional mismatches with less inlining
...@@ -591,6 +604,11 @@ KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) ...@@ -591,6 +604,11 @@ KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
# conserve stack if available # conserve stack if available
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack) KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
# check for 'asm goto'
ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
endif
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
# But warn user when we do so # But warn user when we do so
warn-assign = \ warn-assign = \
......
arch/Kconfig
浏览文件 @ 7d7a48b7
...@@ -158,4 +158,7 @@ config HAVE_PERF_EVENTS_NMI ...@@ -158,4 +158,7 @@ config HAVE_PERF_EVENTS_NMI
subsystem. Also has support for calculating CPU cycle events subsystem. Also has support for calculating CPU cycle events
to determine how many clock cycles in a given period. to determine how many clock cycles in a given period.
config HAVE_ARCH_JUMP_LABEL
bool
source "kernel/gcov/Kconfig" source "kernel/gcov/Kconfig"
arch/alpha/Kconfig
浏览文件 @ 7d7a48b7
...@@ -9,6 +9,7 @@ config ALPHA ...@@ -9,6 +9,7 @@ config ALPHA
select HAVE_IDE select HAVE_IDE
select HAVE_OPROFILE select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS select HAVE_SYSCALL_WRAPPERS
select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS select HAVE_DMA_ATTRS
help help
......
arch/alpha/include/asm/irqflags.h 0 → 100644
浏览文件 @ 7d7a48b7
#ifndef __ALPHA_IRQFLAGS_H
#define __ALPHA_IRQFLAGS_H
#include <asm/system.h>
#define IPL_MIN 0
#define IPL_SW0 1
#define IPL_SW1 2
#define IPL_DEV0 3
#define IPL_DEV1 4
#define IPL_TIMER 5
#define IPL_PERF 6
#define IPL_POWERFAIL 6
#define IPL_MCHECK 7
#define IPL_MAX 7
#ifdef CONFIG_ALPHA_BROKEN_IRQ_MASK
#undef IPL_MIN
#define IPL_MIN __min_ipl
extern int __min_ipl;
#endif
#define getipl() (rdps() & 7)
#define setipl(ipl) ((void) swpipl(ipl))
static inline unsigned long arch_local_save_flags(void)
{
return rdps();
}
static inline void arch_local_irq_disable(void)
{
setipl(IPL_MAX);
barrier();
}
static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags = swpipl(IPL_MAX);
barrier();
return flags;
}
static inline void arch_local_irq_enable(void)
{
barrier();
setipl(IPL_MIN);
}
static inline void arch_local_irq_restore(unsigned long flags)
{
barrier();
setipl(flags);
barrier();
}
static inline bool arch_irqs_disabled_flags(unsigned long flags)
{
return flags == IPL_MAX;
}
static inline bool arch_irqs_disabled(void)
{
return arch_irqs_disabled_flags(getipl());
}
#endif /* __ALPHA_IRQFLAGS_H */
arch/alpha/include/asm/perf_event.h
浏览文件 @ 7d7a48b7
#ifndef __ASM_ALPHA_PERF_EVENT_H #ifndef __ASM_ALPHA_PERF_EVENT_H
#define __ASM_ALPHA_PERF_EVENT_H #define __ASM_ALPHA_PERF_EVENT_H
/* Alpha only supports software events through this interface. */
extern void set_perf_event_pending(void);
#define PERF_EVENT_INDEX_OFFSET 0
#ifdef CONFIG_PERF_EVENTS #ifdef CONFIG_PERF_EVENTS
extern void init_hw_perf_events(void); extern void init_hw_perf_events(void);
#else #else
......
arch/alpha/include/asm/system.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/alpha/kernel/perf_event.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/alpha/kernel/time.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/Kconfig.debug
浏览文件 @ 7d7a48b7
...@@ -2,6 +2,20 @@ menu "Kernel hacking" ...@@ -2,6 +2,20 @@ menu "Kernel hacking"
source "lib/Kconfig.debug" source "lib/Kconfig.debug"
config STRICT_DEVMEM
bool "Filter access to /dev/mem"
depends on MMU
---help---
If this option is disabled, you allow userspace (root) access to all
of memory, including kernel and userspace memory. Accidental
access to this is obviously disastrous, but specific access can
be used by people debugging the kernel.
If this option is switched on, the /dev/mem file only allows
userspace access to memory mapped peripherals.
If in doubt, say Y.
# RMK wants arm kernels compiled with frame pointers or stack unwinding. # RMK wants arm kernels compiled with frame pointers or stack unwinding.
# If you know what you are doing and are willing to live without stack # If you know what you are doing and are willing to live without stack
# traces, you can get a slightly smaller kernel by setting this option to # traces, you can get a slightly smaller kernel by setting this option to
...@@ -27,6 +41,11 @@ config ARM_UNWIND ...@@ -27,6 +41,11 @@ config ARM_UNWIND
the performance is not affected. Currently, this feature the performance is not affected. Currently, this feature
only works with EABI compilers. If unsure say Y. only works with EABI compilers. If unsure say Y.
config OLD_MCOUNT
bool
depends on FUNCTION_TRACER && FRAME_POINTER
default y
config DEBUG_USER config DEBUG_USER
bool "Verbose user fault messages" bool "Verbose user fault messages"
help help
......
arch/arm/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/gic.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/icst.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/pl330.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/sa1111.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/scoop.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/common/uengine.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/kirkwood_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/mx27_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/mx31pdk_defconfig 已删除 100644 → 0
浏览文件 @ e4072a9a
此差异已折叠。
arch/arm/configs/mx3_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/mx51_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/realview_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/configs/u300_defconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/assembler.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/cacheflush.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/cachetype.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/elf.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/ftrace.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/hw_breakpoint.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/hw_irq.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/io.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/ioctls.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/irqflags.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/mach/arch.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/mmu_context.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/module.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/perf_event.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/pgtable.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/processor.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/ptrace.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/seccomp.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/smp_mpidr.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/smp_plat.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/system.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/thread_info.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/include/asm/tlbflush.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/armksyms.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/asm-offsets.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/debug.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/entry-armv.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/entry-common.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/etm.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/ftrace.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/head-common.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/head-nommu.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/head.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/hw_breakpoint.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/irq.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/module.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/perf_event.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/process.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/ptrace.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/smp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/unwind.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/kernel/vmlinux.lds.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-aaec2000/aaed2000.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-1arm.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-cam60.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-cap9adk.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-carmeva.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-cpu9krea.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-cpuat91.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-csb337.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-csb637.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-dk.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-eb9200.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-ecbat91.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-eco920.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-ek.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-flexibity.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-kafa.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-kb9202.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-sam9rlek.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-at91/board-yl-9200.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-bcmring/arch.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-bcmring/dma.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-bcmring/irq.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/autcpu12.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/cdb89712.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/ceiva.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/clep7312.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/fortunet.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-clps711x/p720t.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-cns3xxx/cns3420vb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-dove/dove-db-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ebsa110/core.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/adssphere.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/edb93xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/gesbc9312.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/micro9.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/simone.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/snappercl15.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ep93xx/ts72xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-footbridge/cats-hw.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-footbridge/ebsa285.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-footbridge/personal.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-gemini/board-rut1xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-gemini/board-wbd111.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-gemini/board-wbd222.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-h720x/h7201-eval.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-h720x/h7202-eval.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/clock-imx1.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/clock-imx21.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/clock-imx27.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/devices-imx1.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/devices-imx21.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/devices-imx27.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/devices.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-cpuimx27.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-imx27_visstrim_m10.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-imx27lite.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-mx1ads.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-mx21ads.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-mx27_3ds.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-mx27ads.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-mxt_td60.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-pca100.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-pcm038.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-imx/mach-scb9328.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop13xx/iq81340mc.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop13xx/iq81340sc.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop13xx/msi.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop32x/em7210.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop32x/glantank.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop32x/iq31244.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop32x/iq80321.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop32x/n2100.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop33x/iq80331.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-iop33x/iq80332.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp2000/enp2611.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2400.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2800.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2x01.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp23xx/espresso.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp23xx/ixdp2351.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp23xx/roadrunner.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/avila-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/coyote-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/fsg-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/goramo_mlr.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/nslu2-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ixp4xx/vulcan-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/d2net_v2-setup.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/dockstar-setup.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/include/mach/leds-netxbig.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/lacie_v2-common.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-kirkwood/lacie_v2-common.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ks8695/board-acs5k.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ks8695/board-dsm320.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ks8695/board-micrel.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-l7200/include/mach/debug-macro.S 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-lpc32xx/phy3250.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/aspenite.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/avengers_lite.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/common.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/flint.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/include/mach/teton_bga.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/jasper.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/pxa168.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/tavorevb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/teton_bga.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mmp/ttc_dkb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-halibut.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-mahimahi.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-msm7x27.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-msm7x30.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-msm8x60.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-qsd8x50.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-sapphire.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/board-trout.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/clock-dummy.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/devices-msm7x30.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/devices-msm8x60-iommu.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/devices-qsd8x50.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpio.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpio_hw.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux-7x30.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux-8x50.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux-v1.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux-v1.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux-v2.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/gpiomux.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/entry-macro-qgic.S 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/entry-macro-vic.S 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/io.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/iommu.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/irqs-8x60.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/msm_iomap-8x60.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/include/mach/smp.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/io.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/iommu.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/iommu_dev.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/last_radio_log.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/smd_debug.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-msm/timer.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/clock.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/devices-imx25.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/devices.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/mach-cpuimx25.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx25/mach-mx25_3ds.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/clock-imx31.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/clock-imx35.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/devices-imx31.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/devices-imx35.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/devices.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-cpuimx35.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-mx31_3ds.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-mx31ads.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-mx31lilly.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-mx31lite.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-mx35_3ds.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-pcm037.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-pcm037_eet.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-pcm043.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mach-qong.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx3/mm.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/board-cpuimx51.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/board-cpuimx51sd.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/board-mx51_3ds.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/board-mx51_efikamx.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/clock-mx51.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/devices-imx51.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/devices.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-mxc91231/magx-zn5.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-netx/nxdb500.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-netx/nxdkn.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-netx/nxeb500hmi.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-fsample.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-generic.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-h2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-h3.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-osk.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-palmte.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-palmtt.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-palmz71.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap1/board-sx1.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-2430sdp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-3430sdp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-3630sdp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-4430sdp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-apollon.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-cm-t35.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-generic.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-h4.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-ldp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-n8x0.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-overo.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-rx51.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-zoom2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/board-zoom3.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/hsmmc.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-omap2/usb-musb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-orion5x/d2net-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-orion5x/mss2-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-orion5x/ts209-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-orion5x/ts409-setup.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pnx4008/core.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/balloon3.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/capc7117.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/cm-x2xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/cm-x300.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/colibri-pxa270.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/colibri-pxa300.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/colibri-pxa320.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/corgi.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/cpufreq-pxa3xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/csb726.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/devices.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/devices.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/em-x270.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/eseries.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/ezx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/generic.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/generic.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/gumstix.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/h5000.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/himalaya.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/hx4700.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/icontrol.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/idp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/include/mach/pxa3xx-u2d.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/littleton.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/lpd270.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/lubbock.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/magician.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/mainstone.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/mioa701.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/mp900.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmld.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmt5.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmtc.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmte2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmtreo.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmtx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/palmz72.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/pcm027.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/poodle.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/pxa3xx-ulpi.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/pxa3xx.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/pxa930.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/raumfeld.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/saar.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/spitz.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/stargate2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/tavorevb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/tavorevb3.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/tosa.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/trizeps4.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/viper.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/vpac270.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/xcep.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/z2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/zeus.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-pxa/zylonite.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-realview/core.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-rpc/riscpc.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-bast.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-h1940.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-n30.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-otom.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-qt2410.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2410/mach-vr1000.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2412/mach-jive.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2412/mach-vstms.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2440/mach-anubis.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2440/mach-gta02.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2440/mach-osiris.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2440/mach-rx1950.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c2440/mach-rx3715.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c64xx/mach-hmt.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c64xx/mach-ncp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s3c64xx/mach-smartq.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p6440/include/mach/map.h 已删除 100644 → 0
浏览文件 @ e4072a9a
此差异已折叠。
arch/arm/mach-s5p6442/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/clock-s5p6450.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/clock.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/include/mach/i2c.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/include/mach/map.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/include/mach/regs-clock.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/include/mach/s5p64x0-clock.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/include/mach/uncompress.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5p64x0/mach-smdk6450.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pc100/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv210/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv210/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv210/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv210/mach-aquila.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv210/mach-goni.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-s5pv310/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/assabet.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/badge4.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/cerf.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/collie.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/cpu-sa1100.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/h3100.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/h3600.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/hackkit.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/jornada720.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/lart.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/pleb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/shannon.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-sa1100/simpad.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-shark/core.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/Kconfig 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/Makefile 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/Makefile.boot 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/board-tcc8000-sdk.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/clock.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/common.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/devices.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/io.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/irq.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tcc8k/time.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-tegra/board-harmony.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-u300/dummyspichip.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-u300/spi.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-u300/u300.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/board-mop500-regulators.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/board-mop500-sdi.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/board-mop500.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/board-mop500.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/board-u5500.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/cpu-db5500.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/cpu-db8500.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/hotplug.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/include/mach/mbox.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/include/mach/prcmu-regs.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/include/mach/prcmu.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/mbox.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/modem_irq.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/pins-db5500.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/pins-db8500.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/platsmp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/prcmu.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-ux500/ste-dma40-db5500.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mach-vexpress/ct-ca9x4.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/cache-v6.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/cache-v7.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/copypage-v4mc.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/copypage-v6.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/copypage-xscale.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/dma-mapping.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/fault-armv.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/fault.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/flush.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/init.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/mmap.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/mmu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm1020.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm1020e.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm1022.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm1026.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm6_7.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm720.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm740.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm7tdmi.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm920.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm922.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm925.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm926.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm940.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm946.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-arm9tdmi.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-fa526.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-feroceon.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-mohawk.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-sa110.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-sa1100.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-v6.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-v7.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-xsc3.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/proc-xscale.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/mm/tlb-v7.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/nwfpe/milieu.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/nwfpe/softfloat-macros
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/nwfpe/softfloat-specialize
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/nwfpe/softfloat.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/nwfpe/softfloat.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/oprofile/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/oprofile/common.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/audmux-v2.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/platform-esdhc.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/platform-fec.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/platform-imx-dma.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/devices/platform-imx-ssi.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/ehci.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/epit.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/gpio.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/include/mach/board-mx31ads.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/include/mach/esdhc.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/include/mach/iram.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-mxc/iram_alloc.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-nomadik/gpio.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-omap/fb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-omap/iommu-debug.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/clock.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/cpu.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/dev-uart.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-s5p/include/plat/s5p6450.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/Kconfig 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/Makefile 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/clock.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/clkdev.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/clock.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/debug-macro.S 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/entry-macro.S 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/hardware.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/io.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/irqs.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/memory.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/system.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/tcc8k-regs.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/timex.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/uncompress.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/include/mach/vmalloc.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/arm/plat-tcc/system.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/avr32/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/avr32/boards/mimc200/fram.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/avr32/include/asm/ioctls.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/avr32/include/asm/irqflags.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/Makefile
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/configs/BF527-AD7160-EVAL_defconfig 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/configs/BF527-TLL6527M_defconfig 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/Kbuild
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/bfin_ppi.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/cachectl.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/ipipe.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/ptrace.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/serial.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/system.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/include/asm/unistd.h
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/bfin_gpio.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/ipipe.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/kgdb_test.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/process.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/ptrace.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/sys_bfin.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/kernel/trace.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf518/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf527/boards/ad7160eval.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf527/boards/tll6527m.c 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf527/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf533/include/mach/fio_flag.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf533/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf537/Kconfig
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf537/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf538/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf548/dma.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf548/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf561/coreb.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf561/include/mach/pll.h 0 → 100644
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-bf561/smp.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-common/cpufreq.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-common/entry.S
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mach-common/pm.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/blackfin/mm/init.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/cris/arch-v10/drivers/ds1302.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/cris/arch-v10/drivers/gpio.c
浏览文件 @ 7d7a48b7
此差异已折叠。
arch/cris/arch-v10/drivers/i2c.c
浏览文件 @ 7d7a48b7
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或