Merge remote-tracking branch 'wireless-next/master' into mac80211-next
This commit is contained in:
commit
c4de673b77
15
CREDITS
15
CREDITS
|
@ -2576,7 +2576,7 @@ S: Toronto, Ontario
|
|||
S: Canada
|
||||
|
||||
N: Zwane Mwaikambo
|
||||
E: zwane@arm.linux.org.uk
|
||||
E: zwanem@gmail.com
|
||||
D: Various driver hacking
|
||||
D: Lowlevel x86 kernel hacking
|
||||
D: General debugging
|
||||
|
@ -2808,8 +2808,7 @@ S: Ottawa, Ontario
|
|||
S: Canada K2P 0X8
|
||||
|
||||
N: Mikael Pettersson
|
||||
E: mikpe@it.uu.se
|
||||
W: http://user.it.uu.se/~mikpe/linux/
|
||||
E: mikpelinux@gmail.com
|
||||
D: Miscellaneous fixes
|
||||
|
||||
N: Reed H. Petty
|
||||
|
@ -2896,6 +2895,11 @@ S: Framewood Road
|
|||
S: Wexham SL3 6PJ
|
||||
S: United Kingdom
|
||||
|
||||
N: Richard Purdie
|
||||
E: rpurdie@rpsys.net
|
||||
D: Backlight subsystem maintainer
|
||||
S: United Kingdom
|
||||
|
||||
N: Daniel Quinlan
|
||||
E: quinlan@pathname.com
|
||||
W: http://www.pathname.com/~quinlan/
|
||||
|
@ -3153,6 +3157,11 @@ N: Dipankar Sarma
|
|||
E: dipankar@in.ibm.com
|
||||
D: RCU
|
||||
|
||||
N: Yoshinori Sato
|
||||
E: ysato@users.sourceforge.jp
|
||||
D: uClinux for Renesas H8/300 (H8300)
|
||||
D: http://uclinux-h8.sourceforge.jp/
|
||||
|
||||
N: Hannu Savolainen
|
||||
E: hannu@opensound.com
|
||||
D: Maintainer of the sound drivers until 2.1.x days.
|
||||
|
|
|
@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first.
|
|||
|
||||
It's up to the developer to place their interfaces in the category they
|
||||
wish for it to start out in.
|
||||
|
||||
|
||||
Notable bits of non-ABI, which should not under any circumstances be considered
|
||||
stable:
|
||||
|
||||
- Kconfig. Userspace should not rely on the presence or absence of any
|
||||
particular Kconfig symbol, in /proc/config.gz, in the copy of .config
|
||||
commonly installed to /boot, or in any invocation of the kernel build
|
||||
process.
|
||||
|
||||
- Kernel-internal symbols. Do not rely on the presence, absence, location, or
|
||||
type of any kernel symbol, either in System.map files or the kernel binary
|
||||
itself. See Documentation/stable_api_nonsense.txt.
|
||||
|
|
|
@ -37,8 +37,8 @@ Description:
|
|||
that the USB device has been connected to the machine. This
|
||||
file is read-only.
|
||||
Users:
|
||||
PowerTOP <power@bughost.org>
|
||||
http://www.lesswatts.org/projects/powertop/
|
||||
PowerTOP <powertop@lists.01.org>
|
||||
https://01.org/powertop/
|
||||
|
||||
What: /sys/bus/usb/device/.../power/active_duration
|
||||
Date: January 2008
|
||||
|
@ -57,8 +57,8 @@ Description:
|
|||
will give an integer percentage. Note that this does not
|
||||
account for counter wrap.
|
||||
Users:
|
||||
PowerTOP <power@bughost.org>
|
||||
http://www.lesswatts.org/projects/powertop/
|
||||
PowerTOP <powertop@lists.01.org>
|
||||
https://01.org/powertop/
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend
|
||||
Date: January 2008
|
||||
|
|
|
@ -61,6 +61,12 @@ Description: Interface for making ib_srp connect to a new target.
|
|||
interrupt is handled by a different CPU then the comp_vector
|
||||
parameter can be used to spread the SRP completion workload
|
||||
over multiple CPU's.
|
||||
* tl_retry_count, a number in the range 2..7 specifying the
|
||||
IB RC retry count.
|
||||
* queue_size, the maximum number of commands that the
|
||||
initiator is allowed to queue per SCSI host. The default
|
||||
value for this parameter is 62. The lowest supported value
|
||||
is 2.
|
||||
|
||||
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
|
||||
Date: January 2, 2006
|
||||
|
@ -153,6 +159,13 @@ Contact: linux-rdma@vger.kernel.org
|
|||
Description: InfiniBand service ID used for establishing communication with
|
||||
the SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/sgid
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: InfiniBand GID of the source port used for communication with
|
||||
the SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/zero_req_lim
|
||||
Date: September 20, 2006
|
||||
KernelVersion: 2.6.18
|
||||
|
|
|
@ -5,6 +5,24 @@ Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
|||
Description: Instructs an SRP initiator to disconnect from a target and to
|
||||
remove all LUNs imported from that target.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/dev_loss_tmo
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a transport
|
||||
layer error has been observed before removing a target port.
|
||||
Zero means immediate removal. Setting this attribute to "off"
|
||||
will disable the dev_loss timer.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/fast_io_fail_tmo
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a transport
|
||||
layer error has been observed before failing I/O. Zero means
|
||||
failing I/O immediately. Setting this attribute to "off" will
|
||||
disable the fast_io_fail timer.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id
|
||||
Date: June 27, 2007
|
||||
KernelVersion: 2.6.24
|
||||
|
@ -12,8 +30,29 @@ Contact: linux-scsi@vger.kernel.org
|
|||
Description: 16-byte local SRP port identifier in hexadecimal format. An
|
||||
example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/reconnect_delay
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a reconnect
|
||||
attempt failed before retrying. Setting this attribute to
|
||||
"off" will disable time-based reconnecting.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/roles
|
||||
Date: June 27, 2007
|
||||
KernelVersion: 2.6.24
|
||||
Contact: linux-scsi@vger.kernel.org
|
||||
Description: Role of the remote port. Either "SRP Initiator" or "SRP Target".
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/state
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: State of the transport layer used for communication with the
|
||||
remote port. "running" if the transport layer is operational;
|
||||
"blocked" if a transport layer error has been encountered but
|
||||
the fast_io_fail_tmo timer has not yet fired; "fail-fast"
|
||||
after the fast_io_fail_tmo timer has fired and before the
|
||||
"dev_loss_tmo" timer has fired; "lost" after the
|
||||
"dev_loss_tmo" timer has fired and before the port is finally
|
||||
removed.
|
||||
|
|
31
Documentation/ABI/testing/configfs-usb-gadget-mass-storage
Normal file
31
Documentation/ABI/testing/configfs-usb-gadget-mass-storage
Normal file
|
@ -0,0 +1,31 @@
|
|||
What: /config/usb-gadget/gadget/functions/mass_storage.name
|
||||
Date: Oct 2013
|
||||
KenelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
stall - Set to permit function to halt bulk endpoints.
|
||||
Disabled on some USB devices known not to work
|
||||
correctly. You should set it to true.
|
||||
num_buffers - Number of pipeline buffers. Valid numbers
|
||||
are 2..4. Available only if
|
||||
CONFIG_USB_GADGET_DEBUG_FILES is set.
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
|
||||
Date: Oct 2013
|
||||
KenelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
file - The path to the backing file for the LUN.
|
||||
Required if LUN is not marked as removable.
|
||||
ro - Flag specifying access to the LUN shall be
|
||||
read-only. This is implied if CD-ROM emulation
|
||||
is enabled as well as when it was impossible
|
||||
to open "filename" in R/W mode.
|
||||
removable - Flag specifying that LUN shall be indicated as
|
||||
being removable.
|
||||
cdrom - Flag specifying that LUN shall be reported as
|
||||
being a CD-ROM.
|
||||
nofua - Flag specifying that FUA flag
|
||||
in SCSI WRITE(10,12)
|
|
@ -79,7 +79,7 @@ Description:
|
|||
correspond to externally available input one of the named
|
||||
versions may be used. The number must always be specified and
|
||||
unique to allow association with event codes. Units after
|
||||
application of scale and offset are microvolts.
|
||||
application of scale and offset are millivolts.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
|
||||
KernelVersion: 2.6.35
|
||||
|
@ -90,7 +90,7 @@ Description:
|
|||
physically equivalent inputs when non differential readings are
|
||||
separately available. In differential only parts, then all that
|
||||
is required is a consistent labeling. Units after application
|
||||
of scale and offset are microvolts.
|
||||
of scale and offset are millivolts.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
|
||||
KernelVersion: 3.2
|
||||
|
@ -537,6 +537,62 @@ Description:
|
|||
value is in raw device units or in processed units (as _raw
|
||||
and _input do on sysfs direct channel read attributes).
|
||||
|
||||
What: /sys/.../events/in_accel_x_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_accel_x_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_accel_x_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_accel_y_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_accel_y_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_accel_y_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_accel_z_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_accel_z_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_accel_z_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_anglvel_x_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_anglvel_x_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_anglvel_x_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_anglvel_y_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_anglvel_y_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_anglvel_y_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_anglvel_z_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_anglvel_z_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_anglvel_z_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_magn_x_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_magn_x_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_magn_x_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_magn_y_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_magn_y_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_magn_y_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_magn_z_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_magn_z_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_magn_z_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_voltageY_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_voltageY_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_voltageY_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_tempY_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_tempY_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_tempY_thresh_either_hysteresis
|
||||
What: /sys/.../events/in_illuminance0_thresh_falling_hysteresis
|
||||
what: /sys/.../events/in_illuminance0_thresh_rising_hysteresis
|
||||
what: /sys/.../events/in_illuminance0_thresh_either_hysteresis
|
||||
what: /sys/.../events/in_proximity0_thresh_falling_hysteresis
|
||||
what: /sys/.../events/in_proximity0_thresh_rising_hysteresis
|
||||
what: /sys/.../events/in_proximity0_thresh_either_hysteresis
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the hysteresis of threshold that the device is comparing
|
||||
against for the events enabled by
|
||||
<type>Y[_name]_thresh[_(rising|falling)]_hysteresis.
|
||||
If separate attributes exist for the two directions, but
|
||||
direction is not specified for this attribute, then a single
|
||||
hysteresis value applies to both directions.
|
||||
For falling events the hysteresis is added to the _value attribute for
|
||||
this event to get the upper threshold for when the event goes back to
|
||||
normal, for rising events the hysteresis is subtracted from the _value
|
||||
attribute. E.g. if in_voltage0_raw_thresh_rising_value is set to 1200
|
||||
and in_voltage0_raw_thresh_rising_hysteresis is set to 50. The event
|
||||
will get activated once in_voltage0_raw goes above 1200 and will become
|
||||
deactived again once the value falls below 1150.
|
||||
|
||||
What: /sys/.../events/in_accel_x_raw_roc_rising_value
|
||||
What: /sys/.../events/in_accel_x_raw_roc_falling_value
|
||||
What: /sys/.../events/in_accel_y_raw_roc_rising_value
|
||||
|
@ -811,3 +867,14 @@ Description:
|
|||
Writing '1' stores the current device configuration into
|
||||
on-chip EEPROM. After power-up or chip reset the device will
|
||||
automatically load the saved configuration.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_intensity_red_integration_time
|
||||
What: /sys/.../iio:deviceX/in_intensity_green_integration_time
|
||||
What: /sys/.../iio:deviceX/in_intensity_blue_integration_time
|
||||
What: /sys/.../iio:deviceX/in_intensity_clear_integration_time
|
||||
What: /sys/.../iio:deviceX/in_illuminance_integration_time
|
||||
KernelVersion: 3.12
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to get/set the integration time in
|
||||
seconds.
|
||||
|
|
157
Documentation/ABI/testing/sysfs-class-mic.txt
Normal file
157
Documentation/ABI/testing/sysfs-class-mic.txt
Normal file
|
@ -0,0 +1,157 @@
|
|||
What: /sys/class/mic/
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
The mic class directory belongs to Intel MIC devices and
|
||||
provides information per MIC device. An Intel MIC device is a
|
||||
PCIe form factor add-in Coprocessor card based on the Intel Many
|
||||
Integrated Core (MIC) architecture that runs a Linux OS.
|
||||
|
||||
What: /sys/class/mic/mic(x)
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
The directories /sys/class/mic/mic0, /sys/class/mic/mic1 etc.,
|
||||
represent MIC devices (0,1,..etc). Each directory has
|
||||
information specific to that MIC device.
|
||||
|
||||
What: /sys/class/mic/mic(x)/family
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
Provides information about the Coprocessor family for an Intel
|
||||
MIC device. For example - "x100"
|
||||
|
||||
What: /sys/class/mic/mic(x)/stepping
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
Provides information about the silicon stepping for an Intel
|
||||
MIC device. For example - "A0" or "B0"
|
||||
|
||||
What: /sys/class/mic/mic(x)/state
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
When read, this entry provides the current state of an Intel
|
||||
MIC device in the context of the card OS. Possible values that
|
||||
will be read are:
|
||||
"offline" - The MIC device is ready to boot the card OS. On
|
||||
reading this entry after an OSPM resume, a "boot" has to be
|
||||
written to this entry if the card was previously shutdown
|
||||
during OSPM suspend.
|
||||
"online" - The MIC device has initiated booting a card OS.
|
||||
"shutting_down" - The card OS is shutting down.
|
||||
"reset_failed" - The MIC device has failed to reset.
|
||||
"suspending" - The MIC device is currently being prepared for
|
||||
suspend. On reading this entry, a "suspend" has to be written
|
||||
to the state sysfs entry to ensure the card is shutdown during
|
||||
OSPM suspend.
|
||||
"suspended" - The MIC device has been suspended.
|
||||
|
||||
When written, this sysfs entry triggers different state change
|
||||
operations depending upon the current state of the card OS.
|
||||
Acceptable values are:
|
||||
"boot" - Boot the card OS image specified by the combination
|
||||
of firmware, ramdisk, cmdline and bootmode
|
||||
sysfs entries.
|
||||
"reset" - Initiates device reset.
|
||||
"shutdown" - Initiates card OS shutdown.
|
||||
"suspend" - Initiates card OS shutdown and also marks the card
|
||||
as suspended.
|
||||
|
||||
What: /sys/class/mic/mic(x)/shutdown_status
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
An Intel MIC device runs a Linux OS during its operation. This
|
||||
OS can shutdown because of various reasons. When read, this
|
||||
entry provides the status on why the card OS was shutdown.
|
||||
Possible values are:
|
||||
"nop" - shutdown status is not applicable, when the card OS is
|
||||
"online"
|
||||
"crashed" - Shutdown because of a HW or SW crash.
|
||||
"halted" - Shutdown because of a halt command.
|
||||
"poweroff" - Shutdown because of a poweroff command.
|
||||
"restart" - Shutdown because of a restart command.
|
||||
|
||||
What: /sys/class/mic/mic(x)/cmdline
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
An Intel MIC device runs a Linux OS during its operation. Before
|
||||
booting this card OS, it is possible to pass kernel command line
|
||||
options to configure various features in it, similar to
|
||||
self-bootable machines. When read, this entry provides
|
||||
information about the current kernel command line options set to
|
||||
boot the card OS. This entry can be written to change the
|
||||
existing kernel command line options. Typically, the user would
|
||||
want to read the current command line options, append new ones
|
||||
or modify existing ones and then write the whole kernel command
|
||||
line back to this entry.
|
||||
|
||||
What: /sys/class/mic/mic(x)/firmware
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
When read, this sysfs entry provides the path name under
|
||||
/lib/firmware/ where the firmware image to be booted on the
|
||||
card can be found. The entry can be written to change the
|
||||
firmware image location under /lib/firmware/.
|
||||
|
||||
What: /sys/class/mic/mic(x)/ramdisk
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
When read, this sysfs entry provides the path name under
|
||||
/lib/firmware/ where the ramdisk image to be used during card
|
||||
OS boot can be found. The entry can be written to change
|
||||
the ramdisk image location under /lib/firmware/.
|
||||
|
||||
What: /sys/class/mic/mic(x)/bootmode
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
When read, this sysfs entry provides the current bootmode for
|
||||
the card. This sysfs entry can be written with the following
|
||||
valid strings:
|
||||
a) linux - Boot a Linux image.
|
||||
b) elf - Boot an elf image for flash updates.
|
||||
|
||||
What: /sys/class/mic/mic(x)/log_buf_addr
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
An Intel MIC device runs a Linux OS during its operation. For
|
||||
debugging purpose and early kernel boot messages, the user can
|
||||
access the card OS log buffer via debugfs. When read, this entry
|
||||
provides the kernel virtual address of the buffer where the card
|
||||
OS log buffer can be read. This entry is written by the host
|
||||
configuration daemon to set the log buffer address. The correct
|
||||
log buffer address to be written can be found in the System.map
|
||||
file of the card OS.
|
||||
|
||||
What: /sys/class/mic/mic(x)/log_buf_len
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
|
||||
Description:
|
||||
An Intel MIC device runs a Linux OS during its operation. For
|
||||
debugging purpose and early kernel boot messages, the user can
|
||||
access the card OS log buffer via debugfs. When read, this entry
|
||||
provides the kernel virtual address where the card OS log buffer
|
||||
length can be read. This entry is written by host configuration
|
||||
daemon to set the log buffer length address. The correct log
|
||||
buffer length address to be written can be found in the
|
||||
System.map file of the card OS.
|
|
@ -104,7 +104,7 @@ Description:
|
|||
One of the following ASCII strings, representing the device
|
||||
type:
|
||||
|
||||
absent, ram, rom, nor, nand, dataflash, ubi, unknown
|
||||
absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
|
||||
|
||||
What: /sys/class/mtd/mtdX/writesize
|
||||
Date: April 2009
|
||||
|
|
|
@ -1,13 +1,13 @@
|
|||
|
||||
What: /sys/class/net/<iface>/batman-adv/iface_status
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Indicates the status of <iface> as it is seen by batman.
|
||||
|
||||
What: /sys/class/net/<iface>/batman-adv/mesh_iface
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
The /sys/class/net/<iface>/batman-adv/mesh_iface file
|
||||
displays the batman mesh interface this <iface>
|
||||
|
|
|
@ -1,22 +1,23 @@
|
|||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Indicates whether the batman protocol messages of the
|
||||
mesh <mesh_iface> shall be aggregated or not.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
|
||||
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
|
||||
Date: May 2011
|
||||
Contact: Antonio Quartulli <ordex@autistici.org>
|
||||
Contact: Antonio Quartulli <antonio@meshcoding.com>
|
||||
Description:
|
||||
Indicates whether the data traffic going from a
|
||||
wireless client to another wireless client will be
|
||||
silently dropped.
|
||||
silently dropped. <vlan_subdir> is empty when referring
|
||||
to the untagged lan.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/bonding
|
||||
Date: June 2010
|
||||
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
||||
Contact: Simon Wunderlich <sw@simonwunderlich.de>
|
||||
Description:
|
||||
Indicates whether the data traffic going through the
|
||||
mesh will be sent using multiple interfaces at the
|
||||
|
@ -24,7 +25,7 @@ Description:
|
|||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
|
||||
Date: November 2011
|
||||
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
||||
Contact: Simon Wunderlich <sw@simonwunderlich.de>
|
||||
Description:
|
||||
Indicates whether the bridge loop avoidance feature
|
||||
is enabled. This feature detects and avoids loops
|
||||
|
@ -41,21 +42,21 @@ Description:
|
|||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the bandwidth which is propagated by this
|
||||
node if gw_mode was set to 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the state of the gateway features. Can be
|
||||
either 'off', 'client' or 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the selection criteria this node will use
|
||||
to choose a gateway if gw_mode was set to 'client'.
|
||||
|
@ -77,25 +78,14 @@ Description:
|
|||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the interval in milliseconds in which batman
|
||||
sends its protocol messages.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
|
||||
Date: Dec 2011
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the routing procotol this mesh instance
|
||||
uses to find the optimal paths through the mesh.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Each batman node only maintains information about its
|
||||
own local neighborhood, therefore generating graphs
|
||||
showing the topology of the entire mesh is not easily
|
||||
feasible without having a central instance to collect
|
||||
the local topologies from all nodes. This file allows
|
||||
to activate the collecting (server) mode.
|
||||
|
|
152
Documentation/ABI/testing/sysfs-class-powercap
Normal file
152
Documentation/ABI/testing/sysfs-class-powercap
Normal file
|
@ -0,0 +1,152 @@
|
|||
What: /sys/class/powercap/
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
The powercap/ class sub directory belongs to the power cap
|
||||
subsystem. Refer to
|
||||
Documentation/power/powercap/powercap.txt for details.
|
||||
|
||||
What: /sys/class/powercap/<control type>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
A <control type> is a unique name under /sys/class/powercap.
|
||||
Here <control type> determines how the power is going to be
|
||||
controlled. A <control type> can contain multiple power zones.
|
||||
|
||||
What: /sys/class/powercap/<control type>/enabled
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
This allows to enable/disable power capping for a "control type".
|
||||
This status affects every power zone using this "control_type.
|
||||
|
||||
What: /sys/class/powercap/<control type>/<power zone>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
A power zone is a single or a collection of devices, which can
|
||||
be independently monitored and controlled. A power zone sysfs
|
||||
entry is qualified with the name of the <control type>.
|
||||
E.g. intel-rapl:0:1:1.
|
||||
|
||||
What: /sys/class/powercap/<control type>/<power zone>/<child power zone>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Power zones may be organized in a hierarchy in which child
|
||||
power zones provide monitoring and control for a subset of
|
||||
devices under the parent. For example, if there is a parent
|
||||
power zone for a whole CPU package, each CPU core in it can
|
||||
be a child power zone.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/name
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Specifies the name of this power zone.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/energy_uj
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Current energy counter in micro-joules. Write "0" to reset.
|
||||
If the counter can not be reset, then this attribute is
|
||||
read-only.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/max_energy_range_uj
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Range of the above energy counter in micro-joules.
|
||||
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Current power in micro-watts.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/max_power_range_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Range of the above power value in micro-watts.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_name
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Each power zone can define one or more constraints. Each
|
||||
constraint can have an optional name. Here "X" can have values
|
||||
from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Power limit in micro-watts should be applicable for
|
||||
the time window specified by "constraint_X_time_window_us".
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Time window in micro seconds. This is used along with
|
||||
constraint_X_power_limit_uw to define a power constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
|
||||
What: /sys/class/powercap/<control type>/.../constraint_X_max_power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Maximum allowed power in micro watts for this constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/<control type>/.../constraint_X_min_power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Minimum allowed power in micro watts for this constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Maximum allowed time window in micro seconds for this
|
||||
constraint. Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Minimum allowed time window in micro seconds for this
|
||||
constraint. Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/enabled
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description
|
||||
This allows to enable/disable power capping at power zone level.
|
||||
This applies to current power zone and its children.
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/devices/.../power/
|
||||
Date: January 2009
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power directory contains attributes
|
||||
allowing the user space to check and modify some power
|
||||
|
@ -8,7 +8,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup
|
||||
Date: January 2009
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power/wakeup attribute allows the user
|
||||
space to check if the device is enabled to wake up the system
|
||||
|
@ -34,7 +34,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/control
|
||||
Date: January 2009
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power/control attribute allows the user
|
||||
space to control the run-time power management of the device.
|
||||
|
@ -53,7 +53,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/async
|
||||
Date: January 2009
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../async attribute allows the user space to
|
||||
enable or diasble the device's suspend and resume callbacks to
|
||||
|
@ -79,7 +79,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_count
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_count attribute contains the number
|
||||
of signaled wakeup events associated with the device. This
|
||||
|
@ -88,7 +88,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_active_count
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_active_count attribute contains the
|
||||
number of times the processing of wakeup events associated with
|
||||
|
@ -98,7 +98,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_abort_count
|
||||
Date: February 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_abort_count attribute contains the
|
||||
number of times the processing of a wakeup event associated with
|
||||
|
@ -109,7 +109,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_expire_count
|
||||
Date: February 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_expire_count attribute contains the
|
||||
number of times a wakeup event associated with the device has
|
||||
|
@ -119,7 +119,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_active
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_active attribute contains either 1,
|
||||
or 0, depending on whether or not a wakeup event associated with
|
||||
|
@ -129,7 +129,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_total_time_ms
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_total_time_ms attribute contains
|
||||
the total time of processing wakeup events associated with the
|
||||
|
@ -139,7 +139,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_max_time_ms
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_max_time_ms attribute contains
|
||||
the maximum time of processing a single wakeup event associated
|
||||
|
@ -149,7 +149,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_last_time_ms
|
||||
Date: September 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_last_time_ms attribute contains
|
||||
the value of the monotonic clock corresponding to the time of
|
||||
|
@ -160,7 +160,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
|
||||
Date: February 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
|
||||
contains the total time the device has been preventing
|
||||
|
@ -189,7 +189,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/pm_qos_latency_us
|
||||
Date: March 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
|
||||
contains the PM QoS resume latency limit for the given device,
|
||||
|
@ -207,7 +207,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/pm_qos_no_power_off
|
||||
Date: September 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power/pm_qos_no_power_off attribute
|
||||
is used for manipulating the PM QoS "no power off" flag. If
|
||||
|
@ -222,7 +222,7 @@ Description:
|
|||
|
||||
What: /sys/devices/.../power/pm_qos_remote_wakeup
|
||||
Date: September 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/devices/.../power/pm_qos_remote_wakeup attribute
|
||||
is used for manipulating the PM QoS "remote wakeup required"
|
||||
|
|
178
Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos
Normal file
178
Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos
Normal file
|
@ -0,0 +1,178 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/control
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/profile
|
||||
Date: October 2013
|
||||
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. profile holds index of actual profile.
|
||||
This value is persistent, so its value determines the profile
|
||||
that's active when the device is powered on next time.
|
||||
When written, the device activates the set profile immediately.
|
||||
The data has to be 3 bytes long.
|
||||
The device will reject invalid data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_primary
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the default of all keys for
|
||||
a specific profile. Profile index is included in written data.
|
||||
The data has to be 125 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_function
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
function keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 95 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the macro
|
||||
keys for a specific profile. Profile index is included in
|
||||
written data. The data has to be 35 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_thumbster
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
thumbster keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 23 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_extra
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
capslock and function keys for a specific profile. Profile index
|
||||
is included in written data. The data has to be 8 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_easyzone
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
easyzone keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 294 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/key_mask
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one deactivate certain keys like
|
||||
windows and application keys, to prevent accidental presses.
|
||||
Profile index for which this settings occur is included in
|
||||
written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the backlight intensity for
|
||||
a specific profile. Profile index is included in written data.
|
||||
This attribute is only valid for the glow and pro variant.
|
||||
The data has to be 16 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 480
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile indexes are included in written data.
|
||||
The data has to be 2002 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/info
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 8 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/reset
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one reset the device.
|
||||
The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/talk
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger easyshift functionality
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_control
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one switch between stored and custom
|
||||
light settings.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 8 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/stored_lights
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set per-key lighting for different
|
||||
layers.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 1382 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/custom_lights
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the actual per-key lighting.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 20 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set a light macro that is looped
|
||||
whenever the device gets in dimness mode.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 2002 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
|
@ -57,3 +57,21 @@ Description: This attribute is only provided if the device was detected as a
|
|||
Calibration data is already applied by the kernel to all input
|
||||
values but may be used by user-space to perform other
|
||||
transformations.
|
||||
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/pro_calib
|
||||
Date: October 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: David Herrmann <dh.herrmann@gmail.com>
|
||||
Description: This attribute is only provided if the device was detected as a
|
||||
pro-controller. It provides a single line with 4 calibration
|
||||
values for all 4 analog sticks. Format is: "x1:y1 x2:y2". Data
|
||||
is prefixed with a +/-. Each value is a signed 16bit number.
|
||||
Data is encoded as decimal numbers and specifies the offsets of
|
||||
the analog sticks of the pro-controller.
|
||||
Calibration data is already applied by the kernel to all input
|
||||
values but may be used by user-space to perform other
|
||||
transformations.
|
||||
Calibration data is detected by the kernel during device setup.
|
||||
You can write "scan\n" into this file to re-trigger calibration.
|
||||
You can also write data directly in the form "x1:y1 x2:y2" to
|
||||
set the calibration values manually.
|
||||
|
|
22
Documentation/ABI/testing/sysfs-driver-sunxi-sid
Normal file
22
Documentation/ABI/testing/sysfs-driver-sunxi-sid
Normal file
|
@ -0,0 +1,22 @@
|
|||
What: /sys/devices/*/<our-device>/eeprom
|
||||
Date: August 2013
|
||||
Contact: Oliver Schinagl <oliver@schinagl.nl>
|
||||
Description: read-only access to the SID (Security-ID) on current
|
||||
A-series SoC's from Allwinner. Currently supports A10, A10s, A13
|
||||
and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
|
||||
whereas the newer A20 SoC exposes 512 bytes split into sections.
|
||||
Besides the 16 bytes of SID, there's also an SJTAG area,
|
||||
HDMI-HDCP key and some custom keys. Below a quick overview, for
|
||||
details see the user manual:
|
||||
0x000 128 bit root-key (sun[457]i)
|
||||
0x010 128 bit boot-key (sun7i)
|
||||
0x020 64 bit security-jtag-key (sun7i)
|
||||
0x028 16 bit key configuration (sun7i)
|
||||
0x02b 16 bit custom-vendor-key (sun7i)
|
||||
0x02c 320 bit low general key (sun7i)
|
||||
0x040 32 bit read-control access (sun7i)
|
||||
0x064 224 bit low general key (sun7i)
|
||||
0x080 2304 bit HDCP-key (sun7i)
|
||||
0x1a0 768 bit high general key (sun7i)
|
||||
Users: any user space application which wants to read the SID on
|
||||
Allwinner's A-series of CPU's.
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/power/
|
||||
Date: August 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power directory will contain files that will
|
||||
provide a unified interface to the power management
|
||||
|
@ -8,7 +8,7 @@ Description:
|
|||
|
||||
What: /sys/power/state
|
||||
Date: August 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/state file controls the system power state.
|
||||
Reading from this file returns what states are supported,
|
||||
|
@ -22,7 +22,7 @@ Description:
|
|||
|
||||
What: /sys/power/disk
|
||||
Date: September 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/disk file controls the operating mode of the
|
||||
suspend-to-disk mechanism. Reading from this file returns
|
||||
|
@ -67,7 +67,7 @@ Description:
|
|||
|
||||
What: /sys/power/image_size
|
||||
Date: August 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/image_size file controls the size of the image
|
||||
created by the suspend-to-disk mechanism. It can be written a
|
||||
|
@ -84,7 +84,7 @@ Description:
|
|||
|
||||
What: /sys/power/pm_trace
|
||||
Date: August 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/pm_trace file controls the code which saves the
|
||||
last PM event point in the RTC across reboots, so that you can
|
||||
|
@ -133,7 +133,7 @@ Description:
|
|||
|
||||
What: /sys/power/pm_async
|
||||
Date: January 2009
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/pm_async file controls the switch allowing the
|
||||
user space to enable or disable asynchronous suspend and resume
|
||||
|
@ -146,7 +146,7 @@ Description:
|
|||
|
||||
What: /sys/power/wakeup_count
|
||||
Date: July 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/wakeup_count file allows user space to put the
|
||||
system into a sleep state while taking into account the
|
||||
|
@ -161,7 +161,7 @@ Description:
|
|||
|
||||
What: /sys/power/reserved_size
|
||||
Date: May 2011
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/reserved_size file allows user space to control
|
||||
the amount of memory reserved for allocations made by device
|
||||
|
@ -175,7 +175,7 @@ Description:
|
|||
|
||||
What: /sys/power/autosleep
|
||||
Date: April 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/autosleep file can be written one of the strings
|
||||
returned by reads from /sys/power/state. If that happens, a
|
||||
|
@ -192,7 +192,7 @@ Description:
|
|||
|
||||
What: /sys/power/wake_lock
|
||||
Date: February 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/wake_lock file allows user space to create
|
||||
wakeup source objects and activate them on demand (if one of
|
||||
|
@ -219,7 +219,7 @@ Description:
|
|||
|
||||
What: /sys/power/wake_unlock
|
||||
Date: February 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
Description:
|
||||
The /sys/power/wake_unlock file allows user space to deactivate
|
||||
wakeup sources created with the help of /sys/power/wake_lock.
|
||||
|
|
|
@ -101,14 +101,23 @@ style to do this even if your device holds the default setting,
|
|||
because this shows that you did think about these issues wrt. your
|
||||
device.
|
||||
|
||||
The query is performed via a call to dma_set_mask():
|
||||
The query is performed via a call to dma_set_mask_and_coherent():
|
||||
|
||||
int dma_set_mask(struct device *dev, u64 mask);
|
||||
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
|
||||
|
||||
The query for consistent allocations is performed via a call to
|
||||
dma_set_coherent_mask():
|
||||
which will query the mask for both streaming and coherent APIs together.
|
||||
If you have some special requirements, then the following two separate
|
||||
queries can be used instead:
|
||||
|
||||
int dma_set_coherent_mask(struct device *dev, u64 mask);
|
||||
The query for streaming mappings is performed via a call to
|
||||
dma_set_mask():
|
||||
|
||||
int dma_set_mask(struct device *dev, u64 mask);
|
||||
|
||||
The query for consistent allocations is performed via a call
|
||||
to dma_set_coherent_mask():
|
||||
|
||||
int dma_set_coherent_mask(struct device *dev, u64 mask);
|
||||
|
||||
Here, dev is a pointer to the device struct of your device, and mask
|
||||
is a bit mask describing which bits of an address your device
|
||||
|
@ -137,7 +146,7 @@ exactly why.
|
|||
|
||||
The standard 32-bit addressing device would do something like this:
|
||||
|
||||
if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
|
@ -171,22 +180,20 @@ the case would look like this:
|
|||
|
||||
int using_dac, consistent_using_dac;
|
||||
|
||||
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
||||
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
|
||||
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
|
||||
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
dma_set_coherent_mask() will always be able to set the same or a
|
||||
smaller mask as dma_set_mask(). However for the rare case that a
|
||||
The coherent coherent mask will always be able to set the same or a
|
||||
smaller mask as the streaming mask. However for the rare case that a
|
||||
device driver only uses consistent allocations, one would have to
|
||||
check the return value from dma_set_coherent_mask().
|
||||
|
||||
|
@ -199,9 +206,9 @@ address you might do something like:
|
|||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
When dma_set_mask() is successful, and returns zero, the kernel saves
|
||||
away this mask you have provided. The kernel will use this
|
||||
information later when you make DMA mappings.
|
||||
When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
|
||||
returns zero, the kernel saves away this mask you have provided. The
|
||||
kernel will use this information later when you make DMA mappings.
|
||||
|
||||
There is a case which we are aware of at this time, which is worth
|
||||
mentioning in this documentation. If your device supports multiple
|
||||
|
|
|
@ -141,6 +141,14 @@ won't change the current mask settings. It is more intended as an
|
|||
internal API for use by the platform than an external API for use by
|
||||
driver writers.
|
||||
|
||||
int
|
||||
dma_set_mask_and_coherent(struct device *dev, u64 mask)
|
||||
|
||||
Checks to see if the mask is possible and updates the device
|
||||
streaming and coherent DMA mask parameters if it is.
|
||||
|
||||
Returns: 0 if successful and a negative error if not.
|
||||
|
||||
int
|
||||
dma_set_mask(struct device *dev, u64 mask)
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ all pending DMA writes to complete, and thus provides a mechanism to
|
|||
strictly order DMA from a device across all intervening busses and
|
||||
bridges. This barrier is not specific to a particular type of
|
||||
interconnect, it applies to the system as a whole, and so its
|
||||
implementation must account for the idiosyncracies of the system all
|
||||
implementation must account for the idiosyncrasies of the system all
|
||||
the way from the DMA device to memory.
|
||||
|
||||
As an example of a situation where DMA_ATTR_WRITE_BARRIER would be
|
||||
|
@ -60,7 +60,7 @@ such mapping is non-trivial task and consumes very limited resources
|
|||
Buffers allocated with this attribute can be only passed to user space
|
||||
by calling dma_mmap_attrs(). By using this API, you are guaranteeing
|
||||
that you won't dereference the pointer returned by dma_alloc_attr(). You
|
||||
can threat it as a cookie that must be passed to dma_mmap_attrs() and
|
||||
can treat it as a cookie that must be passed to dma_mmap_attrs() and
|
||||
dma_free_attrs(). Make sure that both of these also get this attribute
|
||||
set on each call.
|
||||
|
||||
|
@ -82,7 +82,7 @@ to 'device' domain, what synchronizes CPU caches for the given region
|
|||
(usually it means that the cache has been flushed or invalidated
|
||||
depending on the dma direction). However, next calls to
|
||||
dma_map_{single,page,sg}() for other devices will perform exactly the
|
||||
same sychronization operation on the CPU cache. CPU cache sychronization
|
||||
same synchronization operation on the CPU cache. CPU cache synchronization
|
||||
might be a time consuming operation, especially if the buffers are
|
||||
large, so it is highly recommended to avoid it if possible.
|
||||
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
|
||||
|
|
|
@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h
|
|||
!Ekernel/printk/printk.c
|
||||
!Ekernel/panic.c
|
||||
!Ekernel/sys.c
|
||||
!Ekernel/rcupdate.c
|
||||
!Ekernel/rcu/srcu.c
|
||||
!Ekernel/rcu/tree.c
|
||||
!Ekernel/rcu/tree_plugin.h
|
||||
!Ekernel/rcu/update.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Device Resource Management</title>
|
||||
|
|
|
@ -91,7 +91,6 @@
|
|||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
!Efs/sysfs/symlink.c
|
||||
!Efs/sysfs/bin.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="debugfs">
|
||||
|
|
|
@ -87,7 +87,7 @@
|
|||
<chapter id="rationale">
|
||||
<title>Rationale</title>
|
||||
<para>
|
||||
The original implementation of interrupt handling in Linux is using
|
||||
The original implementation of interrupt handling in Linux uses
|
||||
the __do_IRQ() super-handler, which is able to deal with every
|
||||
type of interrupt logic.
|
||||
</para>
|
||||
|
@ -111,19 +111,19 @@
|
|||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
This split implementation of highlevel IRQ handlers allows us to
|
||||
This split implementation of high-level IRQ handlers allows us to
|
||||
optimize the flow of the interrupt handling for each specific
|
||||
interrupt type. This reduces complexity in that particular codepath
|
||||
interrupt type. This reduces complexity in that particular code path
|
||||
and allows the optimized handling of a given type.
|
||||
</para>
|
||||
<para>
|
||||
The original general IRQ implementation used hw_interrupt_type
|
||||
structures and their ->ack(), ->end() [etc.] callbacks to
|
||||
differentiate the flow control in the super-handler. This leads to
|
||||
a mix of flow logic and lowlevel hardware logic, and it also leads
|
||||
to unnecessary code duplication: for example in i386, there is a
|
||||
ioapic_level_irq and a ioapic_edge_irq irq-type which share many
|
||||
of the lowlevel details but have different flow handling.
|
||||
a mix of flow logic and low-level hardware logic, and it also leads
|
||||
to unnecessary code duplication: for example in i386, there is an
|
||||
ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
|
||||
of the low-level details but have different flow handling.
|
||||
</para>
|
||||
<para>
|
||||
A more natural abstraction is the clean separation of the
|
||||
|
@ -132,23 +132,23 @@
|
|||
<para>
|
||||
Analysing a couple of architecture's IRQ subsystem implementations
|
||||
reveals that most of them can use a generic set of 'irq flow'
|
||||
methods and only need to add the chip level specific code.
|
||||
methods and only need to add the chip-level specific code.
|
||||
The separation is also valuable for (sub)architectures
|
||||
which need specific quirks in the irq flow itself but not in the
|
||||
chip-details - and thus provides a more transparent IRQ subsystem
|
||||
which need specific quirks in the IRQ flow itself but not in the
|
||||
chip details - and thus provides a more transparent IRQ subsystem
|
||||
design.
|
||||
</para>
|
||||
<para>
|
||||
Each interrupt descriptor is assigned its own highlevel flow
|
||||
Each interrupt descriptor is assigned its own high-level flow
|
||||
handler, which is normally one of the generic
|
||||
implementations. (This highlevel flow handler implementation also
|
||||
implementations. (This high-level flow handler implementation also
|
||||
makes it simple to provide demultiplexing handlers which can be
|
||||
found in embedded platforms on various architectures.)
|
||||
</para>
|
||||
<para>
|
||||
The separation makes the generic interrupt handling layer more
|
||||
flexible and extensible. For example, an (sub)architecture can
|
||||
use a generic irq-flow implementation for 'level type' interrupts
|
||||
use a generic IRQ-flow implementation for 'level type' interrupts
|
||||
and add a (sub)architecture specific 'edge type' implementation.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -172,9 +172,9 @@
|
|||
<para>
|
||||
There are three main levels of abstraction in the interrupt code:
|
||||
<orderedlist>
|
||||
<listitem><para>Highlevel driver API</para></listitem>
|
||||
<listitem><para>Highlevel IRQ flow handlers</para></listitem>
|
||||
<listitem><para>Chiplevel hardware encapsulation</para></listitem>
|
||||
<listitem><para>High-level driver API</para></listitem>
|
||||
<listitem><para>High-level IRQ flow handlers</para></listitem>
|
||||
<listitem><para>Chip-level hardware encapsulation</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<sect1 id="Interrupt_control_flow">
|
||||
|
@ -189,16 +189,16 @@
|
|||
which are assigned to this interrupt.
|
||||
</para>
|
||||
<para>
|
||||
Whenever an interrupt triggers, the lowlevel arch code calls into
|
||||
the generic interrupt code by calling desc->handle_irq().
|
||||
This highlevel IRQ handling function only uses desc->irq_data.chip
|
||||
Whenever an interrupt triggers, the low-level architecture code calls
|
||||
into the generic interrupt code by calling desc->handle_irq().
|
||||
This high-level IRQ handling function only uses desc->irq_data.chip
|
||||
primitives referenced by the assigned chip descriptor structure.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="Highlevel_Driver_API">
|
||||
<title>Highlevel Driver API</title>
|
||||
<title>High-level Driver API</title>
|
||||
<para>
|
||||
The highlevel Driver API consists of following functions:
|
||||
The high-level Driver API consists of following functions:
|
||||
<itemizedlist>
|
||||
<listitem><para>request_irq()</para></listitem>
|
||||
<listitem><para>free_irq()</para></listitem>
|
||||
|
@ -216,7 +216,7 @@
|
|||
</para>
|
||||
</sect1>
|
||||
<sect1 id="Highlevel_IRQ_flow_handlers">
|
||||
<title>Highlevel IRQ flow handlers</title>
|
||||
<title>High-level IRQ flow handlers</title>
|
||||
<para>
|
||||
The generic layer provides a set of pre-defined irq-flow methods:
|
||||
<itemizedlist>
|
||||
|
@ -228,7 +228,7 @@
|
|||
<listitem><para>handle_edge_eoi_irq</para></listitem>
|
||||
<listitem><para>handle_bad_irq</para></listitem>
|
||||
</itemizedlist>
|
||||
The interrupt flow handlers (either predefined or architecture
|
||||
The interrupt flow handlers (either pre-defined or architecture
|
||||
specific) are assigned to specific interrupts by the architecture
|
||||
either during bootup or during device initialization.
|
||||
</para>
|
||||
|
@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask();
|
|||
<para>
|
||||
handle_fasteoi_irq provides a generic implementation
|
||||
for interrupts, which only need an EOI at the end of
|
||||
the handler
|
||||
the handler.
|
||||
</para>
|
||||
<para>
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
|
@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi)
|
|||
The generic functions are intended for 'clean' architectures and chips,
|
||||
which have no platform-specific IRQ handling quirks. If an architecture
|
||||
needs to implement quirks on the 'flow' level then it can do so by
|
||||
overriding the highlevel irq-flow handler.
|
||||
overriding the high-level irq-flow handler.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="Delayed_interrupt_disable">
|
||||
|
@ -419,9 +419,9 @@ if (desc->irq_data.chip->irq_eoi)
|
|||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="Chiplevel_hardware_encapsulation">
|
||||
<title>Chiplevel hardware encapsulation</title>
|
||||
<title>Chip-level hardware encapsulation</title>
|
||||
<para>
|
||||
The chip level hardware descriptor structure irq_chip
|
||||
The chip-level hardware descriptor structure irq_chip
|
||||
contains all the direct chip relevant functions, which
|
||||
can be utilized by the irq flow implementations.
|
||||
<itemizedlist>
|
||||
|
@ -429,14 +429,14 @@ if (desc->irq_data.chip->irq_eoi)
|
|||
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
|
||||
<listitem><para>irq_mask()</para></listitem>
|
||||
<listitem><para>irq_unmask()</para></listitem>
|
||||
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
|
||||
<listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
|
||||
<listitem><para>irq_retrigger() - Optional</para></listitem>
|
||||
<listitem><para>irq_set_type() - Optional</para></listitem>
|
||||
<listitem><para>irq_set_wake() - Optional</para></listitem>
|
||||
</itemizedlist>
|
||||
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
|
||||
handler(s) to use these basic units of lowlevel functionality.
|
||||
handler(s) to use these basic units of low-level functionality.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi)
|
|||
<title>__do_IRQ entry point</title>
|
||||
<para>
|
||||
The original implementation __do_IRQ() was an alternative entry
|
||||
point for all types of interrupts. It not longer exists.
|
||||
point for all types of interrupts. It no longer exists.
|
||||
</para>
|
||||
<para>
|
||||
This handler turned out to be not suitable for all
|
||||
|
@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi)
|
|||
<chapter id="genericchip">
|
||||
<title>Generic interrupt chip</title>
|
||||
<para>
|
||||
To avoid copies of identical implementations of irq chips the
|
||||
To avoid copies of identical implementations of IRQ chips the
|
||||
core provides a configurable generic interrupt chip
|
||||
implementation. Developers should check carefuly whether the
|
||||
generic chip fits their needs before implementing the same
|
||||
functionality slightly different themself.
|
||||
functionality slightly differently themselves.
|
||||
</para>
|
||||
!Ekernel/irq/generic-chip.c
|
||||
</chapter>
|
||||
|
|
|
@ -1958,7 +1958,7 @@ machines due to caching.
|
|||
<chapter id="apiref-mutex">
|
||||
<title>Mutex API reference</title>
|
||||
!Iinclude/linux/mutex.h
|
||||
!Ekernel/mutex.c
|
||||
!Ekernel/locking/mutex.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="apiref-futex">
|
||||
|
|
|
@ -1222,8 +1222,6 @@ in this page</entry>
|
|||
#define NAND_BBT_VERSION 0x00000100
|
||||
/* Create a bbt if none axists */
|
||||
#define NAND_BBT_CREATE 0x00000200
|
||||
/* Search good / bad pattern through all pages of a block */
|
||||
#define NAND_BBT_SCANALLPAGES 0x00000400
|
||||
/* Write bbt if neccecary */
|
||||
#define NAND_BBT_WRITE 0x00001000
|
||||
/* Read and write back block contents when writing bbt */
|
||||
|
|
|
@ -525,8 +525,9 @@ corresponding register block for you.
|
|||
6. Other interesting functions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
pci_find_slot() Find pci_dev corresponding to given bus and
|
||||
slot numbers.
|
||||
pci_get_domain_bus_and_slot() Find pci_dev corresponding to given domain,
|
||||
bus and slot and number. If the device is
|
||||
found, its reference count is increased.
|
||||
pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3)
|
||||
pci_find_capability() Find specified capability in device's capability
|
||||
list.
|
||||
|
@ -582,7 +583,8 @@ having sane locking.
|
|||
|
||||
pci_find_device() Superseded by pci_get_device()
|
||||
pci_find_subsys() Superseded by pci_get_subsys()
|
||||
pci_find_slot() Superseded by pci_get_slot()
|
||||
pci_find_slot() Superseded by pci_get_domain_bus_and_slot()
|
||||
pci_get_slot() Superseded by pci_get_domain_bus_and_slot()
|
||||
|
||||
|
||||
The alternative is the traditional PCI device driver that walks PCI
|
||||
|
|
|
@ -202,8 +202,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||
updater uses call_rcu_sched() or synchronize_sched(), then
|
||||
the corresponding readers must disable preemption, possibly
|
||||
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
|
||||
If the updater uses synchronize_srcu() or call_srcu(),
|
||||
the the corresponding readers must use srcu_read_lock() and
|
||||
If the updater uses synchronize_srcu() or call_srcu(), then
|
||||
the corresponding readers must use srcu_read_lock() and
|
||||
srcu_read_unlock(), and with the same srcu_struct. The rules for
|
||||
the expedited primitives are the same as for their non-expedited
|
||||
counterparts. Mixing things up will result in confusion and
|
||||
|
|
|
@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
This kernel configuration parameter defines the period of time
|
||||
that RCU will wait from the beginning of a grace period until it
|
||||
issues an RCU CPU stall warning. This time period is normally
|
||||
sixty seconds.
|
||||
21 seconds.
|
||||
|
||||
This configuration parameter may be changed at runtime via the
|
||||
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
|
||||
this parameter is checked only at the beginning of a cycle.
|
||||
So if you are 30 seconds into a 70-second stall, setting this
|
||||
So if you are 10 seconds into a 40-second stall, setting this
|
||||
sysfs parameter to (say) five will shorten the timeout for the
|
||||
-next- stall, or the following warning for the current stall
|
||||
(assuming the stall lasts long enough). It will not affect the
|
||||
|
@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE
|
|||
also dump the stacks of any tasks that are blocking the current
|
||||
RCU-preempt grace period.
|
||||
|
||||
RCU_CPU_STALL_INFO
|
||||
CONFIG_RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
print out additional per-CPU diagnostic information, including
|
||||
|
@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA
|
|||
Although the lockdep facility is extremely useful, it does add
|
||||
some overhead. Therefore, under CONFIG_PROVE_RCU, the
|
||||
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
|
||||
giving an RCU CPU stall warning message.
|
||||
giving an RCU CPU stall warning message. (This is a cpp
|
||||
macro, not a kernel configuration parameter.)
|
||||
|
||||
RCU_STALL_RAT_DELAY
|
||||
|
||||
|
@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY
|
|||
However, if the offending CPU does not detect its own stall in
|
||||
the number of jiffies specified by RCU_STALL_RAT_DELAY, then
|
||||
some other CPU will complain. This delay is normally set to
|
||||
two jiffies.
|
||||
two jiffies. (This is a cpp macro, not a kernel configuration
|
||||
parameter.)
|
||||
|
||||
When a CPU detects that it is stalling, it will print a message similar
|
||||
to the following:
|
||||
|
@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message:
|
|||
|
||||
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
|
||||
|
||||
This is rare, but does happen from time to time in real life.
|
||||
This is rare, but does happen from time to time in real life. It is also
|
||||
possible for a zero-jiffy stall to be flagged in this case, depending
|
||||
on how the stall warning and the grace-period initialization happen to
|
||||
interact. Please note that it is not possible to entirely eliminate this
|
||||
sort of false positive without resorting to things like stop_machine(),
|
||||
which is overkill for this sort of problem.
|
||||
|
||||
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
|
@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace.
|
|||
If you can reliably trigger the stall, ftrace can be quite helpful.
|
||||
|
||||
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
|
||||
and with RCU's event tracing.
|
||||
and with RCU's event tracing. For information on RCU's event tracing,
|
||||
see include/trace/events/rcu.h.
|
||||
|
|
|
@ -4,4 +4,4 @@ CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
|
|||
|
||||
When to use this method is described in detail on the
|
||||
Linux/ACPI home page:
|
||||
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
|
||||
https://01.org/linux-acpi/documentation/overriding-dsdt
|
||||
|
|
|
@ -295,10 +295,6 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
|
|||
specifies the path to the controller. In order to use these GPIOs in Linux
|
||||
we need to translate them to the Linux GPIO numbers.
|
||||
|
||||
The driver can do this by including <linux/acpi_gpio.h> and then calling
|
||||
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
|
||||
negative errno if there was no translation found.
|
||||
|
||||
In a simple case of just getting the Linux GPIO number from device
|
||||
resources one can use acpi_get_gpio_by_index() helper function. It takes
|
||||
pointer to the device and index of the GpioIo/GpioInt descriptor in the
|
||||
|
@ -322,3 +318,25 @@ suitable to the gpiolib before passing them.
|
|||
|
||||
In case of GpioInt resource an additional call to gpio_to_irq() must be
|
||||
done before calling request_irq().
|
||||
|
||||
Note that the above API is ACPI specific and not recommended for drivers
|
||||
that need to support non-ACPI systems. The recommended way is to use
|
||||
the descriptor based GPIO interfaces. The above example looks like this
|
||||
when converted to the GPIO desc:
|
||||
|
||||
#include <linux/gpio/consumer.h>
|
||||
...
|
||||
|
||||
struct gpio_desc *irq_desc, *power_desc;
|
||||
|
||||
irq_desc = gpiod_get_index(dev, NULL, 1);
|
||||
if (IS_ERR(irq_desc))
|
||||
/* handle error */
|
||||
|
||||
power_desc = gpiod_get_index(dev, NULL, 0);
|
||||
if (IS_ERR(power_desc))
|
||||
/* handle error */
|
||||
|
||||
/* Now we can use the GPIO descriptors */
|
||||
|
||||
See also Documentation/gpio.txt.
|
||||
|
|
|
@ -88,6 +88,7 @@ EBU Armada family
|
|||
MV78230
|
||||
MV78260
|
||||
MV78460
|
||||
NOTE: not to be confused with the non-SMP 78xx0 SoCs
|
||||
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
|
||||
No public datasheet available.
|
||||
|
|
|
@ -10,6 +10,10 @@ SunXi family
|
|||
Linux kernel mach directory: arch/arm/mach-sunxi
|
||||
|
||||
Flavors:
|
||||
* ARM926 based SoCs
|
||||
- Allwinner F20 (sun3i)
|
||||
+ Not Supported
|
||||
|
||||
* ARM Cortex-A8 based SoCs
|
||||
- Allwinner A10 (sun4i)
|
||||
+ Datasheet
|
||||
|
@ -25,4 +29,24 @@ SunXi family
|
|||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
|
||||
+ User Manual
|
||||
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-08-08%29.pdf
|
||||
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf
|
||||
|
||||
* Dual ARM Cortex-A7 based SoCs
|
||||
- Allwinner A20 (sun7i)
|
||||
+ User Manual
|
||||
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
|
||||
|
||||
- Allwinner A23
|
||||
+ Not Supported
|
||||
|
||||
* Quad ARM Cortex-A7 based SoCs
|
||||
- Allwinner A31 (sun6i)
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
|
||||
|
||||
- Allwinner A31s (sun6i)
|
||||
+ Not Supported
|
||||
|
||||
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
|
||||
- Allwinner A80
|
||||
+ Not Supported
|
|
@ -115,9 +115,10 @@ Before jumping into the kernel, the following conditions must be met:
|
|||
External caches (if present) must be configured and disabled.
|
||||
|
||||
- Architected timers
|
||||
CNTFRQ must be programmed with the timer frequency.
|
||||
If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
|
||||
set where available.
|
||||
CNTFRQ must be programmed with the timer frequency and CNTVOFF must
|
||||
be programmed with a consistent value on all CPUs. If entering the
|
||||
kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
|
||||
available.
|
||||
|
||||
- Coherency
|
||||
All CPUs to be booted by the kernel must be part of the same coherency
|
||||
|
@ -130,30 +131,46 @@ Before jumping into the kernel, the following conditions must be met:
|
|||
the kernel image will be entered must be initialised by software at a
|
||||
higher exception level to prevent execution in an UNKNOWN state.
|
||||
|
||||
The requirements described above for CPU mode, caches, MMUs, architected
|
||||
timers, coherency and system registers apply to all CPUs. All CPUs must
|
||||
enter the kernel in the same exception level.
|
||||
|
||||
The boot loader is expected to enter the kernel on each CPU in the
|
||||
following manner:
|
||||
|
||||
- The primary CPU must jump directly to the first instruction of the
|
||||
kernel image. The device tree blob passed by this CPU must contain
|
||||
for each CPU node:
|
||||
|
||||
1. An 'enable-method' property. Currently, the only supported value
|
||||
for this field is the string "spin-table".
|
||||
|
||||
2. A 'cpu-release-addr' property identifying a 64-bit,
|
||||
zero-initialised memory location.
|
||||
an 'enable-method' property for each cpu node. The supported
|
||||
enable-methods are described below.
|
||||
|
||||
It is expected that the bootloader will generate these device tree
|
||||
properties and insert them into the blob prior to kernel entry.
|
||||
|
||||
- Any secondary CPUs must spin outside of the kernel in a reserved area
|
||||
of memory (communicated to the kernel by a /memreserve/ region in the
|
||||
- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
|
||||
property in their cpu node. This property identifies a
|
||||
naturally-aligned 64-bit zero-initalised memory location.
|
||||
|
||||
These CPUs should spin outside of the kernel in a reserved area of
|
||||
memory (communicated to the kernel by a /memreserve/ region in the
|
||||
device tree) polling their cpu-release-addr location, which must be
|
||||
contained in the reserved region. A wfe instruction may be inserted
|
||||
to reduce the overhead of the busy-loop and a sev will be issued by
|
||||
the primary CPU. When a read of the location pointed to by the
|
||||
cpu-release-addr returns a non-zero value, the CPU must jump directly
|
||||
to this value.
|
||||
cpu-release-addr returns a non-zero value, the CPU must jump to this
|
||||
value. The value will be written as a single 64-bit little-endian
|
||||
value, so CPUs must convert the read value to their native endianness
|
||||
before jumping to it.
|
||||
|
||||
- CPUs with a "psci" enable method should remain outside of
|
||||
the kernel (i.e. outside of the regions of memory described to the
|
||||
kernel in the memory node, or in a reserved area of memory described
|
||||
to the kernel by a /memreserve/ region in the device tree). The
|
||||
kernel will issue CPU_ON calls as described in ARM document number ARM
|
||||
DEN 0022A ("Power State Coordination Interface System Software on ARM
|
||||
processors") to bring CPUs into the kernel.
|
||||
|
||||
The device tree should contain a 'psci' node, as described in
|
||||
Documentation/devicetree/bindings/arm/psci.txt.
|
||||
|
||||
- Secondary CPU general-purpose register settings
|
||||
x0 = 0 (reserved for future use)
|
||||
|
|
|
@ -21,7 +21,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to
|
|||
TTBR0.
|
||||
|
||||
|
||||
AArch64 Linux memory layout:
|
||||
AArch64 Linux memory layout with 4KB pages:
|
||||
|
||||
Start End Size Use
|
||||
-----------------------------------------------------------------------
|
||||
|
@ -39,13 +39,38 @@ ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
|
|||
|
||||
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
|
||||
|
||||
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
|
||||
ffffffbffbe10000 ffffffbcffffffff ~2MB [guard]
|
||||
|
||||
ffffffbffc000000 ffffffbfffffffff 64MB modules
|
||||
|
||||
ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map
|
||||
|
||||
|
||||
AArch64 Linux memory layout with 64KB pages:
|
||||
|
||||
Start End Size Use
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 000003ffffffffff 4TB user
|
||||
|
||||
fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc
|
||||
|
||||
fffffdfbffff0000 fffffdfbffffffff 64KB [guard page]
|
||||
|
||||
fffffdfc00000000 fffffdfdffffffff 8GB vmemmap
|
||||
|
||||
fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap]
|
||||
|
||||
fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device
|
||||
|
||||
fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O space
|
||||
|
||||
fffffdfffbe10000 fffffdfffbffffff ~2MB [guard]
|
||||
|
||||
fffffdfffc000000 fffffdffffffffff 64MB modules
|
||||
|
||||
fffffe0000000000 ffffffffffffffff 2TB kernel logical memory map
|
||||
|
||||
|
||||
Translation table lookup with 4KB pages:
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|
|
|
@ -18,17 +18,17 @@ this byte for application use, with the following caveats:
|
|||
parameters containing user virtual addresses *must* have
|
||||
their top byte cleared before trapping to the kernel.
|
||||
|
||||
(2) Tags are not guaranteed to be preserved when delivering
|
||||
signals. This means that signal handlers in applications
|
||||
making use of tags cannot rely on the tag information for
|
||||
user virtual addresses being maintained for fields inside
|
||||
siginfo_t. One exception to this rule is for signals raised
|
||||
in response to debug exceptions, where the tag information
|
||||
(2) Non-zero tags are not preserved when delivering signals.
|
||||
This means that signal handlers in applications making use
|
||||
of tags cannot rely on the tag information for user virtual
|
||||
addresses being maintained for fields inside siginfo_t.
|
||||
One exception to this rule is for signals raised in response
|
||||
to watchpoint debug exceptions, where the tag information
|
||||
will be preserved.
|
||||
|
||||
(3) Special care should be taken when using tagged pointers,
|
||||
since it is likely that C compilers will not hazard two
|
||||
addresses differing only in the upper bits.
|
||||
virtual addresses differing only in the upper byte.
|
||||
|
||||
The architecture prevents the use of a tagged PC, so the upper byte will
|
||||
be set to a sign-extension of bit 55 on exception return.
|
||||
|
|
|
@ -4,7 +4,8 @@ Kernel driver lp855x
|
|||
Backlight driver for LP855x ICs
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
|
||||
LP8557
|
||||
|
||||
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||
|
||||
|
@ -24,7 +25,7 @@ Value : pwm based or register based
|
|||
|
||||
2) chip_id
|
||||
The lp855x chip id.
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
|
||||
|
||||
Platform data for lp855x
|
||||
------------------------
|
||||
|
|
|
@ -6,6 +6,8 @@ capability.txt
|
|||
- Generic Block Device Capability (/sys/block/<device>/capability)
|
||||
cfq-iosched.txt
|
||||
- CFQ IO scheduler tunables
|
||||
cmdline-partition.txt
|
||||
- how to specify block device partitions on kernel command line
|
||||
data-integrity.txt
|
||||
- Block data integrity
|
||||
deadline-iosched.txt
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
Embedded device command line partition
|
||||
Embedded device command line partition parsing
|
||||
=====================================================================
|
||||
|
||||
Read block device partition table from command line.
|
||||
The partition used for fixed block device (eMMC) embedded device.
|
||||
It is no MBR, save storage space. Bootloader can be easily accessed
|
||||
Support for reading the block device partition table from the command line.
|
||||
It is typically used for fixed block (eMMC) embedded devices.
|
||||
It has no MBR, so saves storage space. Bootloader can be easily accessed
|
||||
by absolute address of data on the block device.
|
||||
Users can easily change the partition.
|
||||
|
||||
|
|
|
@ -39,15 +39,15 @@ Module configuration options
|
|||
============================
|
||||
|
||||
If you use the floppy driver as a module, use the following syntax:
|
||||
modprobe floppy <options>
|
||||
modprobe floppy floppy="<options>"
|
||||
|
||||
Example:
|
||||
modprobe floppy omnibook messages
|
||||
modprobe floppy floppy="omnibook messages"
|
||||
|
||||
If you need certain options enabled every time you load the floppy driver,
|
||||
you can put:
|
||||
|
||||
options floppy omnibook messages
|
||||
options floppy floppy="omnibook messages"
|
||||
|
||||
in a configuration file in /etc/modprobe.d/.
|
||||
|
||||
|
|
|
@ -573,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical
|
|||
node. One of the use cases is evaluating application performance by
|
||||
combining this information with the application's CPU allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
|
||||
per-node page counts including "hierarchical_<counter>" which sums up all
|
||||
hierarchical children's values in addition to the memcg's own value.
|
||||
|
||||
The ouput format of memory.numa_stat is:
|
||||
|
||||
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
|
||||
And we have total = file + anon + unevictable.
|
||||
The "total" count is sum of file + anon + unevictable.
|
||||
|
||||
6. Hierarchy support
|
||||
|
||||
|
|
|
@ -71,7 +71,7 @@ static int netlink_send(int s, struct cn_msg *msg)
|
|||
nlh->nlmsg_seq = seq++;
|
||||
nlh->nlmsg_pid = getpid();
|
||||
nlh->nlmsg_type = NLMSG_DONE;
|
||||
nlh->nlmsg_len = NLMSG_LENGTH(size - sizeof(*nlh));
|
||||
nlh->nlmsg_len = size;
|
||||
nlh->nlmsg_flags = 0;
|
||||
|
||||
m = NLMSG_DATA(nlh);
|
||||
|
|
|
@ -23,8 +23,8 @@ Contents:
|
|||
1.1 Initialization
|
||||
1.2 Per-CPU Initialization
|
||||
1.3 verify
|
||||
1.4 target or setpolicy?
|
||||
1.5 target
|
||||
1.4 target/target_index or setpolicy?
|
||||
1.5 target/target_index
|
||||
1.6 setpolicy
|
||||
2. Frequency Table Helpers
|
||||
|
||||
|
@ -56,7 +56,8 @@ cpufreq_driver.init - A pointer to the per-CPU initialization
|
|||
cpufreq_driver.verify - A pointer to a "verification" function.
|
||||
|
||||
cpufreq_driver.setpolicy _or_
|
||||
cpufreq_driver.target - See below on the differences.
|
||||
cpufreq_driver.target/
|
||||
target_index - See below on the differences.
|
||||
|
||||
And optionally
|
||||
|
||||
|
@ -66,7 +67,7 @@ cpufreq_driver.resume - A pointer to a per-CPU resume function
|
|||
which is called with interrupts disabled
|
||||
and _before_ the pre-suspend frequency
|
||||
and/or policy is restored by a call to
|
||||
->target or ->setpolicy.
|
||||
->target/target_index or ->setpolicy.
|
||||
|
||||
cpufreq_driver.attr - A pointer to a NULL-terminated list of
|
||||
"struct freq_attr" which allow to
|
||||
|
@ -103,8 +104,8 @@ policy->governor must contain the "default policy" for
|
|||
this CPU. A few moments later,
|
||||
cpufreq_driver.verify and either
|
||||
cpufreq_driver.setpolicy or
|
||||
cpufreq_driver.target is called with
|
||||
these values.
|
||||
cpufreq_driver.target/target_index is called
|
||||
with these values.
|
||||
|
||||
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
|
||||
frequency table helpers might be helpful. See the section 2 for more information
|
||||
|
@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase
|
|||
policy->max first, and only if this is no solution, decrease policy->min.
|
||||
|
||||
|
||||
1.4 target or setpolicy?
|
||||
1.4 target/target_index or setpolicy?
|
||||
----------------------------
|
||||
|
||||
Most cpufreq drivers or even most cpu frequency scaling algorithms
|
||||
only allow the CPU to be set to one frequency. For these, you use the
|
||||
->target call.
|
||||
->target/target_index call.
|
||||
|
||||
Some cpufreq-capable processors switch the frequency between certain
|
||||
limits on their own. These shall use the ->setpolicy call
|
||||
|
||||
|
||||
1.4. target
|
||||
1.4. target/target_index
|
||||
-------------
|
||||
|
||||
The target_index call has two arguments: struct cpufreq_policy *policy,
|
||||
and unsigned int index (into the exposed frequency table).
|
||||
|
||||
The CPUfreq driver must set the new frequency when called here. The
|
||||
actual frequency must be determined by freq_table[index].frequency.
|
||||
|
||||
Deprecated:
|
||||
----------
|
||||
The target call has three arguments: struct cpufreq_policy *policy,
|
||||
unsigned int target_frequency, unsigned int relation.
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most
|
|||
cpu frequency scaling algorithms only offer the CPU to be set to one
|
||||
frequency. In order to offer dynamic frequency scaling, the cpufreq
|
||||
core must be able to tell these drivers of a "target frequency". So
|
||||
these specific drivers will be transformed to offer a "->target"
|
||||
these specific drivers will be transformed to offer a "->target/target_index"
|
||||
call instead of the existing "->setpolicy" call. For "longrun", all
|
||||
stays the same, though.
|
||||
|
||||
|
@ -71,7 +71,7 @@ CPU can be set to switch independently | CPU can only be set
|
|||
/ the limits of policy->{min,max}
|
||||
/ \
|
||||
/ \
|
||||
Using the ->setpolicy call, Using the ->target call,
|
||||
Using the ->setpolicy call, Using the ->target/target_index call,
|
||||
the limits and the the frequency closest
|
||||
"policy" is set. to target_freq is set.
|
||||
It is assured that it
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
Rusty Russell <rusty@rustcorp.com.au>
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>
|
||||
i386:
|
||||
Zwane Mwaikambo <zwane@arm.linux.org.uk>
|
||||
Zwane Mwaikambo <zwanem@gmail.com>
|
||||
ppc64:
|
||||
Nathan Lynch <nathanl@austin.ibm.com>
|
||||
Joel Schopp <jschopp@austin.ibm.com>
|
||||
|
|
|
@ -25,5 +25,4 @@ kernel configuration and platform will be selected by cpuidle.
|
|||
|
||||
Interfaces:
|
||||
extern int cpuidle_register_governor(struct cpuidle_governor *gov);
|
||||
extern void cpuidle_unregister_governor(struct cpuidle_governor *gov);
|
||||
struct cpuidle_governor
|
||||
|
|
|
@ -30,8 +30,10 @@ multiqueue
|
|||
|
||||
This policy is the default.
|
||||
|
||||
The multiqueue policy has two sets of 16 queues: one set for entries
|
||||
waiting for the cache and another one for those in the cache.
|
||||
The multiqueue policy has three sets of 16 queues: one set for entries
|
||||
waiting for the cache and another two for those in the cache (a set for
|
||||
clean entries and a set for dirty entries).
|
||||
|
||||
Cache entries in the queues are aged based on logical time. Entry into
|
||||
the cache is based on variable thresholds and queue selection is based
|
||||
on hit count on entry. The policy aims to take different cache miss
|
||||
|
|
|
@ -68,10 +68,11 @@ So large block sizes are bad because they waste cache space. And small
|
|||
block sizes are bad because they increase the amount of metadata (both
|
||||
in core and on disk).
|
||||
|
||||
Writeback/writethrough
|
||||
----------------------
|
||||
Cache operating modes
|
||||
---------------------
|
||||
|
||||
The cache has two modes, writeback and writethrough.
|
||||
The cache has three operating modes: writeback, writethrough and
|
||||
passthrough.
|
||||
|
||||
If writeback, the default, is selected then a write to a block that is
|
||||
cached will go only to the cache and the block will be marked dirty in
|
||||
|
@ -81,8 +82,31 @@ If writethrough is selected then a write to a cached block will not
|
|||
complete until it has hit both the origin and cache devices. Clean
|
||||
blocks should remain clean.
|
||||
|
||||
If passthrough is selected, useful when the cache contents are not known
|
||||
to be coherent with the origin device, then all reads are served from
|
||||
the origin device (all reads miss the cache) and all writes are
|
||||
forwarded to the origin device; additionally, write hits cause cache
|
||||
block invalidates. To enable passthrough mode the cache must be clean.
|
||||
Passthrough mode allows a cache device to be activated without having to
|
||||
worry about coherency. Coherency that exists is maintained, although
|
||||
the cache will gradually cool as writes take place. If the coherency of
|
||||
the cache can later be verified, or established through use of the
|
||||
"invalidate_cblocks" message, the cache device can be transitioned to
|
||||
writethrough or writeback mode while still warm. Otherwise, the cache
|
||||
contents can be discarded prior to transitioning to the desired
|
||||
operating mode.
|
||||
|
||||
A simple cleaner policy is provided, which will clean (write back) all
|
||||
dirty blocks in a cache. Useful for decommissioning a cache.
|
||||
dirty blocks in a cache. Useful for decommissioning a cache or when
|
||||
shrinking a cache. Shrinking the cache's fast device requires all cache
|
||||
blocks, in the area of the cache being removed, to be clean. If the
|
||||
area being removed from the cache still contains dirty blocks the resize
|
||||
will fail. Care must be taken to never reduce the volume used for the
|
||||
cache's fast device until the cache is clean. This is of particular
|
||||
importance if writeback mode is used. Writethrough and passthrough
|
||||
modes already maintain a clean cache. Future support to partially clean
|
||||
the cache, above a specified threshold, will allow for keeping the cache
|
||||
warm and in writeback mode during resize.
|
||||
|
||||
Migration throttling
|
||||
--------------------
|
||||
|
@ -161,7 +185,7 @@ Constructor
|
|||
block size : cache unit size in sectors
|
||||
|
||||
#feature args : number of feature arguments passed
|
||||
feature args : writethrough. (The default is writeback.)
|
||||
feature args : writethrough or passthrough (The default is writeback.)
|
||||
|
||||
policy : the replacement policy to use
|
||||
#policy args : an even number of arguments corresponding to
|
||||
|
@ -177,6 +201,13 @@ Optional feature arguments are:
|
|||
back cache block contents later for performance reasons,
|
||||
so they may differ from the corresponding origin blocks.
|
||||
|
||||
passthrough : a degraded mode useful for various cache coherency
|
||||
situations (e.g., rolling back snapshots of
|
||||
underlying storage). Reads and writes always go to
|
||||
the origin. If a write goes to a cached origin
|
||||
block, then the cache block is invalidated.
|
||||
To enable passthrough mode the cache must be clean.
|
||||
|
||||
A policy called 'default' is always registered. This is an alias for
|
||||
the policy we currently think is giving best all round performance.
|
||||
|
||||
|
@ -231,12 +262,26 @@ The message format is:
|
|||
E.g.
|
||||
dmsetup message my_cache 0 sequential_threshold 1024
|
||||
|
||||
|
||||
Invalidation is removing an entry from the cache without writing it
|
||||
back. Cache blocks can be invalidated via the invalidate_cblocks
|
||||
message, which takes an arbitrary number of cblock ranges. Each cblock
|
||||
must be expressed as a decimal value, in the future a variant message
|
||||
that takes cblock ranges expressed in hexidecimal may be needed to
|
||||
better support efficient invalidation of larger caches. The cache must
|
||||
be in passthrough mode when invalidate_cblocks is used.
|
||||
|
||||
invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*
|
||||
|
||||
E.g.
|
||||
dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
The test suite can be found here:
|
||||
|
||||
https://github.com/jthornber/thinp-test-suite
|
||||
https://github.com/jthornber/device-mapper-test-suite
|
||||
|
||||
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
|
||||
/dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'
|
||||
|
|
|
@ -4,12 +4,15 @@ dm-crypt
|
|||
Device-Mapper's "crypt" target provides transparent encryption of block devices
|
||||
using the kernel crypto API.
|
||||
|
||||
For a more detailed description of supported parameters see:
|
||||
http://code.google.com/p/cryptsetup/wiki/DMCrypt
|
||||
|
||||
Parameters: <cipher> <key> <iv_offset> <device path> \
|
||||
<offset> [<#opt_params> <opt_params>]
|
||||
|
||||
<cipher>
|
||||
Encryption cipher and an optional IV generation mode.
|
||||
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
|
||||
(In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
|
||||
Examples:
|
||||
des
|
||||
aes-cbc-essiv:sha256
|
||||
|
@ -19,7 +22,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
|
|||
|
||||
<key>
|
||||
Key used for encryption. It is encoded as a hexadecimal number.
|
||||
You can only use key sizes that are valid for the selected cipher.
|
||||
You can only use key sizes that are valid for the selected cipher
|
||||
in combination with the selected iv mode.
|
||||
Note that for some iv modes the key string can contain additional
|
||||
keys (for example IV seed) so the key contains more parts concatenated
|
||||
into a single string.
|
||||
|
||||
<keycount>
|
||||
Multi-key compatibility mode. You can define <keycount> keys and
|
||||
|
|
|
@ -414,6 +414,7 @@ Your cooperation is appreciated.
|
|||
200 = /dev/net/tun TAP/TUN network device
|
||||
201 = /dev/button/gulpb Transmeta GULP-B buttons
|
||||
202 = /dev/emd/ctl Enhanced Metadisk RAID (EMD) control
|
||||
203 = /dev/cuse Cuse (character device in user-space)
|
||||
204 = /dev/video/em8300 EM8300 DVD decoder control
|
||||
205 = /dev/video/em8300_mv EM8300 DVD decoder video
|
||||
206 = /dev/video/em8300_ma EM8300 DVD decoder audio
|
||||
|
|
24
Documentation/devicetree/bindings/arc/pmu.txt
Normal file
24
Documentation/devicetree/bindings/arc/pmu.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
* ARC Performance Monitor Unit
|
||||
|
||||
The ARC 700 can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits.
|
||||
|
||||
Note that:
|
||||
* ARC 700 refers to a family of ARC processor cores;
|
||||
- There is only one type of PMU available for the whole family;
|
||||
- The PMU may support different sets of events; supported events are probed
|
||||
at boot time, as required by the reference manual.
|
||||
|
||||
* The ARC 700 PMU does not support interrupts; although HW events may be
|
||||
counted, the HW events themselves cannot serve as a trigger for a sample.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,arc700-pmu"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,arc700-pmu";
|
||||
};
|
|
@ -9,9 +9,53 @@ Required properties (in root node):
|
|||
|
||||
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
|
||||
|
||||
In the root node the Integrator/CP must have a /cpcon node pointing
|
||||
to the CP control registers, and the Integrator/AP must have a
|
||||
/syscon node pointing to the Integrator/AP system controller.
|
||||
Required nodes:
|
||||
|
||||
- core-module: the root node to the Integrator platforms must have
|
||||
a core-module with regs and the compatible string
|
||||
"arm,core-module-integrator"
|
||||
|
||||
Required properties for the core module:
|
||||
- regs: the location and size of the core module registers, one
|
||||
range of 0x200 bytes.
|
||||
|
||||
- syscon: the root node of the Integrator platforms must have a
|
||||
system controller node pointong to the control registers,
|
||||
with the compatible string
|
||||
"arm,integrator-ap-syscon"
|
||||
"arm,integrator-cp-syscon"
|
||||
respectively.
|
||||
|
||||
Required properties for the system controller:
|
||||
- regs: the location and size of the system controller registers,
|
||||
one range of 0x100 bytes.
|
||||
|
||||
Required properties for the AP system controller:
|
||||
- interrupts: the AP syscon node must include the logical module
|
||||
interrupts, stated in order of module instance <module 0>,
|
||||
<module 1>, <module 2> ... for the CP system controller this
|
||||
is not required not of any use.
|
||||
|
||||
/dts-v1/;
|
||||
/include/ "integrator.dtsi"
|
||||
|
||||
/ {
|
||||
model = "ARM Integrator/AP";
|
||||
compatible = "arm,integrator-ap";
|
||||
|
||||
core-module@10000000 {
|
||||
compatible = "arm,core-module-integrator";
|
||||
reg = <0x10000000 0x200>;
|
||||
};
|
||||
|
||||
syscon {
|
||||
compatible = "arm,integrator-ap-syscon";
|
||||
reg = <0x11000000 0x100>;
|
||||
interrupt-parent = <&pic>;
|
||||
/* These are the logic module IRQs */
|
||||
interrupts = <9>, <10>, <11>, <12>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
ARM Versatile Application and Platform Baseboards
|
||||
|
|
|
@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
|
|||
Required properties:
|
||||
- compatible: Should be "marvell,mpic"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- msi-controller: Identifies the node as an PCI Message Signaled
|
||||
Interrupt controller.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
|
||||
The cell is the IRQ number
|
||||
|
||||
|
@ -24,6 +26,7 @@ Example:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
reg = <0xd0020a00 0x1d0>,
|
||||
<0xd0021070 0x58>;
|
||||
};
|
||||
|
|
|
@ -7,7 +7,6 @@ Required properties:
|
|||
- interrupts: Should contain the IRQ line for the ADC
|
||||
- atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
|
||||
device
|
||||
- atmel,adc-num-channels: Number of channels available in the ADC
|
||||
- atmel,adc-startup-time: Startup Time of the ADC in microseconds as
|
||||
defined in the datasheet
|
||||
- atmel,adc-vref: Reference voltage in millivolts for the conversions
|
||||
|
@ -24,6 +23,13 @@ Optional properties:
|
|||
resolution will be used.
|
||||
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
|
||||
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
|
||||
- atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this
|
||||
value is set, then adc driver will enable touch screen
|
||||
support.
|
||||
NOTE: when adc touch screen enabled, the adc hardware trigger will be
|
||||
disabled. Since touch screen will occupied the trigger register.
|
||||
- atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
|
||||
make touch detect more precision.
|
||||
|
||||
Optional trigger Nodes:
|
||||
- Required properties:
|
||||
|
|
|
@ -1,7 +1,9 @@
|
|||
Calxeda DDR memory controller
|
||||
|
||||
Properties:
|
||||
- compatible : Should be "calxeda,hb-ddr-ctrl"
|
||||
- compatible : Should be:
|
||||
- "calxeda,hb-ddr-ctrl" for ECX-1000
|
||||
- "calxeda,ecx-2000-ddr-ctrl" for ECX-2000
|
||||
- reg : Address and size for DDR controller registers.
|
||||
- interrupts : Interrupt for DDR controller.
|
||||
|
||||
|
|
|
@ -36,14 +36,18 @@ specific to ARM.
|
|||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Value type: Integer cells. A register entry, expressed as a pair
|
||||
of cells, containing base and size.
|
||||
Definition: A standard property. Specifies base physical
|
||||
address of CCI control registers common to all
|
||||
interfaces.
|
||||
|
||||
- ranges:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Value type: Integer cells. An array of range entries, expressed
|
||||
as a tuple of cells, containing child address,
|
||||
parent address and the size of the region in the
|
||||
child address space.
|
||||
Definition: A standard property. Follow rules in the ePAPR for
|
||||
hierarchical bus addressing. CCI interfaces
|
||||
addresses refer to the parent node addressing
|
||||
|
@ -74,11 +78,49 @@ specific to ARM.
|
|||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Value type: Integer cells. A register entry, expressed
|
||||
as a pair of cells, containing base and
|
||||
size.
|
||||
Definition: the base address and size of the
|
||||
corresponding interface programming
|
||||
registers.
|
||||
|
||||
- CCI PMU node
|
||||
|
||||
Parent node must be CCI interconnect node.
|
||||
|
||||
A CCI pmu node must contain the following properties:
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "arm,cci-400-pmu"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: Integer cells. A register entry, expressed
|
||||
as a pair of cells, containing base and
|
||||
size.
|
||||
Definition: the base address and size of the
|
||||
corresponding interface programming
|
||||
registers.
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: Integer cells. Array of interrupt specifier
|
||||
entries, as defined in
|
||||
../interrupt-controller/interrupts.txt.
|
||||
Definition: list of counter overflow interrupts, one per
|
||||
counter. The interrupts must be specified
|
||||
starting with the cycle counter overflow
|
||||
interrupt, followed by counter0 overflow
|
||||
interrupt, counter1 overflow interrupt,...
|
||||
,counterN overflow interrupt.
|
||||
|
||||
The CCI PMU has an interrupt signal for each
|
||||
counter. The number of interrupts must be
|
||||
equal to the number of counters.
|
||||
|
||||
* CCI interconnect bus masters
|
||||
|
||||
Description: masters in the device tree connected to a CCI port
|
||||
|
@ -144,7 +186,7 @@ Example:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x0 0x2c090000 0 0x1000>;
|
||||
ranges = <0x0 0x0 0x2c090000 0x6000>;
|
||||
ranges = <0x0 0x0 0x2c090000 0x10000>;
|
||||
|
||||
cci_control0: slave-if@1000 {
|
||||
compatible = "arm,cci-400-ctrl-if";
|
||||
|
@ -163,6 +205,16 @@ Example:
|
|||
interface-type = "ace";
|
||||
reg = <0x5000 0x1000>;
|
||||
};
|
||||
|
||||
pmu@9000 {
|
||||
compatible = "arm,cci-400-pmu";
|
||||
reg = <0x9000 0x5000>;
|
||||
interrupts = <0 101 4>,
|
||||
<0 102 4>,
|
||||
<0 103 4>,
|
||||
<0 104 4>,
|
||||
<0 105 4>;
|
||||
};
|
||||
};
|
||||
|
||||
This CCI node corresponds to a CCI component whose control registers sits
|
||||
|
|
|
@ -1,77 +1,384 @@
|
|||
* ARM CPUs binding description
|
||||
=================
|
||||
ARM CPUs bindings
|
||||
=================
|
||||
|
||||
The device tree allows to describe the layout of CPUs in a system through
|
||||
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
|
||||
defining properties for every cpu.
|
||||
|
||||
Bindings for CPU nodes follow the ePAPR standard, available from:
|
||||
Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
|
||||
|
||||
http://devicetree.org
|
||||
https://www.power.org/documentation/epapr-version-1-1/
|
||||
|
||||
For the ARM architecture every CPU node must contain the following properties:
|
||||
with updates for 32-bit and 64-bit ARM systems provided in this document.
|
||||
|
||||
- device_type: must be "cpu"
|
||||
- reg: property matching the CPU MPIDR[23:0] register bits
|
||||
reg[31:24] bits must be set to 0
|
||||
- compatible: should be one of:
|
||||
"arm,arm1020"
|
||||
"arm,arm1020e"
|
||||
"arm,arm1022"
|
||||
"arm,arm1026"
|
||||
"arm,arm720"
|
||||
"arm,arm740"
|
||||
"arm,arm7tdmi"
|
||||
"arm,arm920"
|
||||
"arm,arm922"
|
||||
"arm,arm925"
|
||||
"arm,arm926"
|
||||
"arm,arm940"
|
||||
"arm,arm946"
|
||||
"arm,arm9tdmi"
|
||||
"arm,cortex-a5"
|
||||
"arm,cortex-a7"
|
||||
"arm,cortex-a8"
|
||||
"arm,cortex-a9"
|
||||
"arm,cortex-a15"
|
||||
"arm,arm1136"
|
||||
"arm,arm1156"
|
||||
"arm,arm1176"
|
||||
"arm,arm11mpcore"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
"intel,sa1100"
|
||||
"marvell,feroceon"
|
||||
"marvell,mohawk"
|
||||
"marvell,xsc3"
|
||||
"marvell,xscale"
|
||||
================================
|
||||
Convention used in this document
|
||||
================================
|
||||
|
||||
Example:
|
||||
This document follows the conventions described in the ePAPR v1.1, with
|
||||
the addition:
|
||||
|
||||
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
|
||||
the reg property contained in bits 7 down to 0
|
||||
|
||||
=====================================
|
||||
cpus and cpu node bindings definition
|
||||
=====================================
|
||||
|
||||
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
|
||||
nodes to be present and contain the properties described below.
|
||||
|
||||
- cpus node
|
||||
|
||||
Description: Container of cpu nodes
|
||||
|
||||
The node name must be "cpus".
|
||||
|
||||
A cpus node must define the following properties:
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
|
||||
Definition depends on ARM architecture version and
|
||||
configuration:
|
||||
|
||||
# On uniprocessor ARM architectures previous to v7
|
||||
value must be 1, to enable a simple enumeration
|
||||
scheme for processors that do not have a HW CPU
|
||||
identification register.
|
||||
# On 32-bit ARM 11 MPcore, ARM v7 or later systems
|
||||
value must be 1, that corresponds to CPUID/MPIDR
|
||||
registers sizes.
|
||||
# On ARM v8 64-bit systems value should be set to 2,
|
||||
that corresponds to the MPIDR_EL1 register size.
|
||||
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
|
||||
in the system, #address-cells can be set to 1, since
|
||||
MPIDR_EL1[63:32] bits are not used for CPUs
|
||||
identification.
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be set to 0
|
||||
|
||||
- cpu node
|
||||
|
||||
Description: Describes a CPU in an ARM based system
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- device_type
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "cpu"
|
||||
- reg
|
||||
Usage and definition depend on ARM architecture version and
|
||||
configuration:
|
||||
|
||||
# On uniprocessor ARM architectures previous to v7
|
||||
this property is required and must be set to 0.
|
||||
|
||||
# On ARM 11 MPcore based systems this property is
|
||||
required and matches the CPUID[11:0] register bits.
|
||||
|
||||
Bits [11:0] in the reg cell must be set to
|
||||
bits [11:0] in CPU ID register.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
# On 32-bit ARM v7 or later systems this property is
|
||||
required and matches the CPU MPIDR[23:0] register
|
||||
bits.
|
||||
|
||||
Bits [23:0] in the reg cell must be set to
|
||||
bits [23:0] in MPIDR.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
# On ARM v8 64-bit systems this property is required
|
||||
and matches the MPIDR_EL1 register affinity bits.
|
||||
|
||||
* If cpus node's #address-cells property is set to 2
|
||||
|
||||
The first reg cell bits [7:0] must be set to
|
||||
bits [39:32] of MPIDR_EL1.
|
||||
|
||||
The second reg cell bits [23:0] must be set to
|
||||
bits [23:0] of MPIDR_EL1.
|
||||
|
||||
* If cpus node's #address-cells property is set to 1
|
||||
|
||||
The reg cell bits [23:0] must be set to bits [23:0]
|
||||
of MPIDR_EL1.
|
||||
|
||||
All other bits in the reg cells must be set to 0.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be one of:
|
||||
"arm,arm710t"
|
||||
"arm,arm720t"
|
||||
"arm,arm740t"
|
||||
"arm,arm7ej-s"
|
||||
"arm,arm7tdmi"
|
||||
"arm,arm7tdmi-s"
|
||||
"arm,arm9es"
|
||||
"arm,arm9ej-s"
|
||||
"arm,arm920t"
|
||||
"arm,arm922t"
|
||||
"arm,arm925"
|
||||
"arm,arm926e-s"
|
||||
"arm,arm926ej-s"
|
||||
"arm,arm940t"
|
||||
"arm,arm946e-s"
|
||||
"arm,arm966e-s"
|
||||
"arm,arm968e-s"
|
||||
"arm,arm9tdmi"
|
||||
"arm,arm1020e"
|
||||
"arm,arm1020t"
|
||||
"arm,arm1022e"
|
||||
"arm,arm1026ej-s"
|
||||
"arm,arm1136j-s"
|
||||
"arm,arm1136jf-s"
|
||||
"arm,arm1156t2-s"
|
||||
"arm,arm1156t2f-s"
|
||||
"arm,arm1176jzf"
|
||||
"arm,arm1176jz-s"
|
||||
"arm,arm1176jzf-s"
|
||||
"arm,arm11mpcore"
|
||||
"arm,cortex-a5"
|
||||
"arm,cortex-a7"
|
||||
"arm,cortex-a8"
|
||||
"arm,cortex-a9"
|
||||
"arm,cortex-a15"
|
||||
"arm,cortex-a53"
|
||||
"arm,cortex-a57"
|
||||
"arm,cortex-m0"
|
||||
"arm,cortex-m0+"
|
||||
"arm,cortex-m1"
|
||||
"arm,cortex-m3"
|
||||
"arm,cortex-m4"
|
||||
"arm,cortex-r4"
|
||||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
"intel,sa1100"
|
||||
"marvell,feroceon"
|
||||
"marvell,mohawk"
|
||||
"marvell,pj4a"
|
||||
"marvell,pj4b"
|
||||
"marvell,sheeva-v5"
|
||||
"qcom,krait"
|
||||
"qcom,scorpion"
|
||||
- enable-method
|
||||
Value type: <stringlist>
|
||||
Usage and definition depend on ARM architecture version.
|
||||
# On ARM v8 64-bit this property is required and must
|
||||
be one of:
|
||||
"spin-table"
|
||||
"psci"
|
||||
# On ARM 32-bit systems this property is optional.
|
||||
|
||||
- cpu-release-addr
|
||||
Usage: required for systems that have an "enable-method"
|
||||
property value of "spin-table".
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
# On ARM v8 64-bit systems must be a two cell
|
||||
property identifying a 64-bit zero-initialised
|
||||
memory location.
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
CPU0: cpu@0 {
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x0>;
|
||||
};
|
||||
|
||||
CPU1: cpu@1 {
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x1>;
|
||||
};
|
||||
|
||||
CPU2: cpu@100 {
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x100>;
|
||||
};
|
||||
|
||||
CPU3: cpu@101 {
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x101>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 2 (Cortex-A8 uniprocessor 32-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a8";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,arm926ej-s";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 4 (ARM Cortex-A57 64-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <2>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -21,7 +21,8 @@ Required properties:
|
|||
Optional properties:
|
||||
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
|
||||
during suspend.
|
||||
|
||||
- ti,no-reset-on-init: When present, the module should not be reset at init
|
||||
- ti,no-idle-on-init: When present, the module should not be idled at init
|
||||
|
||||
Example:
|
||||
|
||||
|
|
474
Documentation/devicetree/bindings/arm/topology.txt
Normal file
474
Documentation/devicetree/bindings/arm/topology.txt
Normal file
|
@ -0,0 +1,474 @@
|
|||
===========================================
|
||||
ARM topology binding description
|
||||
===========================================
|
||||
|
||||
===========================================
|
||||
1 - Introduction
|
||||
===========================================
|
||||
|
||||
In an ARM system, the hierarchy of CPUs is defined through three entities that
|
||||
are used to describe the layout of physical CPUs in the system:
|
||||
|
||||
- cluster
|
||||
- core
|
||||
- thread
|
||||
|
||||
The cpu nodes (bindings defined in [1]) represent the devices that
|
||||
correspond to physical CPUs and are to be mapped to the hierarchy levels.
|
||||
|
||||
The bottom hierarchy level sits at core or thread level depending on whether
|
||||
symmetric multi-threading (SMT) is supported or not.
|
||||
|
||||
For instance in a system where CPUs support SMT, "cpu" nodes represent all
|
||||
threads existing in the system and map to the hierarchy level "thread" above.
|
||||
In systems where SMT is not supported "cpu" nodes represent all cores present
|
||||
in the system and map to the hierarchy level "core" above.
|
||||
|
||||
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
|
||||
corresponding to the system hierarchy; syntactically they are defined as device
|
||||
tree nodes.
|
||||
|
||||
The remainder of this document provides the topology bindings for ARM, based
|
||||
on the ePAPR standard, available from:
|
||||
|
||||
http://www.power.org/documentation/epapr-version-1-1/
|
||||
|
||||
If not stated otherwise, whenever a reference to a cpu node phandle is made its
|
||||
value must point to a cpu node compliant with the cpu node bindings as
|
||||
documented in [1].
|
||||
A topology description containing phandles to cpu nodes that are not compliant
|
||||
with bindings standardized in [1] is therefore considered invalid.
|
||||
|
||||
===========================================
|
||||
2 - cpu-map node
|
||||
===========================================
|
||||
|
||||
The ARM CPU topology is defined within the cpu-map node, which is a direct
|
||||
child of the cpus node and provides a container where the actual topology
|
||||
nodes are listed.
|
||||
|
||||
- cpu-map node
|
||||
|
||||
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
|
||||
ARM uniprocessor systems do not require a topology
|
||||
description and therefore should not define a
|
||||
cpu-map node.
|
||||
|
||||
Description: The cpu-map node is just a container node where its
|
||||
subnodes describe the CPU topology.
|
||||
|
||||
Node name must be "cpu-map".
|
||||
|
||||
The cpu-map node's parent node must be the cpus node.
|
||||
|
||||
The cpu-map node's child nodes can be:
|
||||
|
||||
- one or more cluster nodes
|
||||
|
||||
Any other configuration is considered invalid.
|
||||
|
||||
The cpu-map node can only contain three types of child nodes:
|
||||
|
||||
- cluster node
|
||||
- core node
|
||||
- thread node
|
||||
|
||||
whose bindings are described in paragraph 3.
|
||||
|
||||
The nodes describing the CPU topology (cluster/core/thread) can only be
|
||||
defined within the cpu-map node.
|
||||
Any other configuration is consider invalid and therefore must be ignored.
|
||||
|
||||
===========================================
|
||||
2.1 - cpu-map child nodes naming convention
|
||||
===========================================
|
||||
|
||||
cpu-map child nodes must follow a naming convention where the node name
|
||||
must be "clusterN", "coreN", "threadN" depending on the node type (ie
|
||||
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
|
||||
are siblings within a single common parent node must be given a unique and
|
||||
sequential N value, starting from 0).
|
||||
cpu-map child nodes which do not share a common parent node can have the same
|
||||
name (ie same number N as other cpu-map child nodes at different device tree
|
||||
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
|
||||
|
||||
===========================================
|
||||
3 - cluster/core/thread node bindings
|
||||
===========================================
|
||||
|
||||
Bindings for cluster/cpu/thread nodes are defined as follows:
|
||||
|
||||
- cluster node
|
||||
|
||||
Description: must be declared within a cpu-map node, one node
|
||||
per cluster. A system can contain several layers of
|
||||
clustering and cluster nodes can be contained in parent
|
||||
cluster nodes.
|
||||
|
||||
The cluster node name must be "clusterN" as described in 2.1 above.
|
||||
A cluster node can not be a leaf node.
|
||||
|
||||
A cluster node's child nodes must be:
|
||||
|
||||
- one or more cluster nodes; or
|
||||
- one or more core nodes
|
||||
|
||||
Any other configuration is considered invalid.
|
||||
|
||||
- core node
|
||||
|
||||
Description: must be declared in a cluster node, one node per core in
|
||||
the cluster. If the system does not support SMT, core
|
||||
nodes are leaf nodes, otherwise they become containers of
|
||||
thread nodes.
|
||||
|
||||
The core node name must be "coreN" as described in 2.1 above.
|
||||
|
||||
A core node must be a leaf node if SMT is not supported.
|
||||
|
||||
Properties for core nodes that are leaf nodes:
|
||||
|
||||
- cpu
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: a phandle to the cpu node that corresponds to the
|
||||
core node.
|
||||
|
||||
If a core node is not a leaf node (CPUs supporting SMT) a core node's
|
||||
child nodes can be:
|
||||
|
||||
- one or more thread nodes
|
||||
|
||||
Any other configuration is considered invalid.
|
||||
|
||||
- thread node
|
||||
|
||||
Description: must be declared in a core node, one node per thread
|
||||
in the core if the system supports SMT. Thread nodes are
|
||||
always leaf nodes in the device tree.
|
||||
|
||||
The thread node name must be "threadN" as described in 2.1 above.
|
||||
|
||||
A thread node must be a leaf node.
|
||||
|
||||
A thread node must contain the following property:
|
||||
|
||||
- cpu
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: a phandle to the cpu node that corresponds to
|
||||
the thread node.
|
||||
|
||||
===========================================
|
||||
4 - Example dts
|
||||
===========================================
|
||||
|
||||
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <2>;
|
||||
|
||||
cpu-map {
|
||||
cluster0 {
|
||||
cluster0 {
|
||||
core0 {
|
||||
thread0 {
|
||||
cpu = <&CPU0>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU1>;
|
||||
};
|
||||
};
|
||||
|
||||
core1 {
|
||||
thread0 {
|
||||
cpu = <&CPU2>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU3>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
cluster1 {
|
||||
core0 {
|
||||
thread0 {
|
||||
cpu = <&CPU4>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU5>;
|
||||
};
|
||||
};
|
||||
|
||||
core1 {
|
||||
thread0 {
|
||||
cpu = <&CPU6>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU7>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
cluster1 {
|
||||
cluster0 {
|
||||
core0 {
|
||||
thread0 {
|
||||
cpu = <&CPU8>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU9>;
|
||||
};
|
||||
};
|
||||
core1 {
|
||||
thread0 {
|
||||
cpu = <&CPU10>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU11>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
cluster1 {
|
||||
core0 {
|
||||
thread0 {
|
||||
cpu = <&CPU12>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU13>;
|
||||
};
|
||||
};
|
||||
core1 {
|
||||
thread0 {
|
||||
cpu = <&CPU14>;
|
||||
};
|
||||
thread1 {
|
||||
cpu = <&CPU15>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
CPU0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU2: cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU3: cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU4: cpu@10000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU5: cpu@10001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU6: cpu@10100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU7: cpu@10101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU8: cpu@100000000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU9: cpu@100000001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU10: cpu@100000100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU11: cpu@100000101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU12: cpu@100010000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU13: cpu@100010001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU14: cpu@100010100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
CPU15: cpu@100010101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu-map {
|
||||
cluster0 {
|
||||
core0 {
|
||||
cpu = <&CPU0>;
|
||||
};
|
||||
core1 {
|
||||
cpu = <&CPU1>;
|
||||
};
|
||||
core2 {
|
||||
cpu = <&CPU2>;
|
||||
};
|
||||
core3 {
|
||||
cpu = <&CPU3>;
|
||||
};
|
||||
};
|
||||
|
||||
cluster1 {
|
||||
core0 {
|
||||
cpu = <&CPU4>;
|
||||
};
|
||||
core1 {
|
||||
cpu = <&CPU5>;
|
||||
};
|
||||
core2 {
|
||||
cpu = <&CPU6>;
|
||||
};
|
||||
core3 {
|
||||
cpu = <&CPU7>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
CPU0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x0>;
|
||||
};
|
||||
|
||||
CPU1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x1>;
|
||||
};
|
||||
|
||||
CPU2: cpu@2 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x2>;
|
||||
};
|
||||
|
||||
CPU3: cpu@3 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x3>;
|
||||
};
|
||||
|
||||
CPU4: cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x100>;
|
||||
};
|
||||
|
||||
CPU5: cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x101>;
|
||||
};
|
||||
|
||||
CPU6: cpu@102 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x102>;
|
||||
};
|
||||
|
||||
CPU7: cpu@103 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x103>;
|
||||
};
|
||||
};
|
||||
|
||||
===============================================================================
|
||||
[1] ARM Linux kernel documentation
|
||||
Documentation/devicetree/bindings/arm/cpus.txt
|
|
@ -18,6 +18,15 @@ Required properties:
|
|||
Optional properties:
|
||||
|
||||
- interrupts : Interrupt source for parent controllers if the VIC is nested.
|
||||
- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit
|
||||
represents single interrupt source, starting from source 0 at LSb and ending
|
||||
at source 31 at MSb. A bit that is set means that the source is wired and
|
||||
clear means otherwise. If unspecified, defaults to all valid.
|
||||
- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be
|
||||
configured as wake up source for the system. Order of bits is the same as for
|
||||
valid-mask property. A set bit means that this interrupt source can be
|
||||
configured as a wake up source for the system. If unspecied, defaults to all
|
||||
interrupt sources configurable as wake up sources.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -26,4 +35,7 @@ Example:
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x60000 0x1000>;
|
||||
|
||||
valid-mask = <0xffffff7f>;
|
||||
valid-wakeup-mask = <0x0000ff7f>;
|
||||
};
|
||||
|
|
11
Documentation/devicetree/bindings/clock/efm32-clock.txt
Normal file
11
Documentation/devicetree/bindings/clock/efm32-clock.txt
Normal file
|
@ -0,0 +1,11 @@
|
|||
* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "efm32gg,cmu"
|
||||
- reg: Base address and length of the register set
|
||||
- interrupts: Interrupt used by the CMU
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock ID in
|
||||
its "clocks" phandle cell. The header efm32-clk.h contains a list of available
|
||||
IDs.
|
|
@ -215,6 +215,11 @@ clocks and IDs.
|
|||
cko2 200
|
||||
cko 201
|
||||
vdoa 202
|
||||
pll4_audio_div 203
|
||||
lvds1_sel 204
|
||||
lvds2_sel 205
|
||||
lvds1_gate 206
|
||||
lvds2_gate 207
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
29
Documentation/devicetree/bindings/clock/keystone-gate.txt
Normal file
29
Documentation/devicetree/bindings/clock/keystone-gate.txt
Normal file
|
@ -0,0 +1,29 @@
|
|||
Status: Unstable - ABI compatibility may be broken in the future
|
||||
|
||||
Binding for Keystone gate control driver which uses PSC controller IP.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "ti,keystone,psc-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : parent clock phandle
|
||||
- reg : psc control and domain address address space
|
||||
- reg-names : psc control and domain registers
|
||||
- domain-id : psc domain id needed to check the transition state register
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding to override the
|
||||
default output clock name
|
||||
Example:
|
||||
clkusb: clkusb {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,psc-clock";
|
||||
clocks = <&chipclk16>;
|
||||
clock-output-names = "usb";
|
||||
reg = <0x02350008 0xb00>, <0x02350000 0x400>;
|
||||
reg-names = "control", "domain";
|
||||
domain-id = <0>;
|
||||
};
|
84
Documentation/devicetree/bindings/clock/keystone-pll.txt
Normal file
84
Documentation/devicetree/bindings/clock/keystone-pll.txt
Normal file
|
@ -0,0 +1,84 @@
|
|||
Status: Unstable - ABI compatibility may be broken in the future
|
||||
|
||||
Binding for keystone PLLs. The main PLL IP typically has a multiplier,
|
||||
a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
|
||||
and PAPLL are controlled by the memory mapped register where as the Main
|
||||
PLL is controlled by a PLL controller registers along with memory mapped
|
||||
registers.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
|
||||
- clocks : parent clock phandle
|
||||
- reg - pll control0 and pll multipler registers
|
||||
- reg-names : control and multiplier. The multiplier is applicable only for
|
||||
main pll clock
|
||||
- fixed-postdiv : fixed post divider value
|
||||
|
||||
Example:
|
||||
mainpllclk: mainpllclk@2310110 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,main-pll-clock";
|
||||
clocks = <&refclkmain>;
|
||||
reg = <0x02620350 4>, <0x02310110 4>;
|
||||
reg-names = "control", "multiplier";
|
||||
fixed-postdiv = <2>;
|
||||
};
|
||||
|
||||
papllclk: papllclk@2620358 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,pll-clock";
|
||||
clocks = <&refclkmain>;
|
||||
clock-output-names = "pa-pll-clk";
|
||||
reg = <0x02620358 4>;
|
||||
reg-names = "control";
|
||||
fixed-postdiv = <6>;
|
||||
};
|
||||
|
||||
Required properties:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- compatible : shall be "ti,keystone,pll-mux-clock"
|
||||
- clocks : link phandles of parent clocks
|
||||
- reg - pll mux register
|
||||
- bit-shift : number of bits to shift the bit-mask
|
||||
- bit-mask : arbitrary bitmask for programming the mux
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Example:
|
||||
mainmuxclk: mainmuxclk@2310108 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,pll-mux-clock";
|
||||
clocks = <&mainpllclk>, <&refclkmain>;
|
||||
reg = <0x02310108 4>;
|
||||
bit-shift = <23>;
|
||||
bit-mask = <1>;
|
||||
clock-output-names = "mainmuxclk";
|
||||
};
|
||||
|
||||
Required properties:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- compatible : shall be "ti,keystone,pll-divider-clock"
|
||||
- clocks : parent clock phandle
|
||||
- reg - pll mux register
|
||||
- bit-shift : number of bits to shift the bit-mask
|
||||
- bit-mask : arbitrary bitmask for programming the divider
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Example:
|
||||
gemtraceclk: gemtraceclk@2310120 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,pll-divider-clock";
|
||||
clocks = <&mainmuxclk>;
|
||||
reg = <0x02310120 4>;
|
||||
bit-shift = <0>;
|
||||
bit-mask = <8>;
|
||||
clock-output-names = "gemtraceclk";
|
||||
};
|
|
@ -0,0 +1,19 @@
|
|||
* Core Divider Clock bindings for Marvell MVEBU SoCs
|
||||
|
||||
The following is a list of provided IDs and clock names on Armada 370/XP:
|
||||
0 = nand (NAND clock)
|
||||
|
||||
Required properties:
|
||||
- compatible : must be "marvell,armada-370-corediv-clock"
|
||||
- reg : must be the register address of Core Divider control register
|
||||
- #clock-cells : from common clock binding; shall be set to 1
|
||||
- clocks : must be set to the parent's phandle
|
||||
|
||||
Example:
|
||||
|
||||
corediv_clk: corediv-clocks@18740 {
|
||||
compatible = "marvell,armada-370-corediv-clock";
|
||||
reg = <0x18740 0xc>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&pll>;
|
||||
};
|
|
@ -1,10 +1,10 @@
|
|||
* Gated Clock bindings for Marvell Orion SoCs
|
||||
* Gated Clock bindings for Marvell EBU SoCs
|
||||
|
||||
Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save
|
||||
some power. The clock consumer should specify the desired clock by having
|
||||
the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to
|
||||
the corresponding clock gating control bit in HW to ease manual clock lookup
|
||||
in datasheet.
|
||||
Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be
|
||||
gated to save some power. The clock consumer should specify the desired clock
|
||||
by having the clock ID in its "clocks" phandle cell. The clock ID is directly
|
||||
mapped to the corresponding clock gating control bit in HW to ease manual clock
|
||||
lookup in datasheet.
|
||||
|
||||
The following is a list of provided IDs for Armada 370:
|
||||
ID Clock Peripheral
|
||||
|
@ -94,6 +94,8 @@ ID Clock Peripheral
|
|||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
|
||||
"marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
|
||||
"marvell,dove-gating-clock" - for Dove SoC clock gating
|
||||
"marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
|
||||
- reg : shall be the register address of the Clock Gating Control register
|
||||
|
|
|
@ -45,8 +45,8 @@ Additionally, "allwinner,*-gates-clk" clocks require:
|
|||
|
||||
Clock consumers should specify the desired clocks they use with a
|
||||
"clocks" phandle cell. Consumers that are using a gated clock should
|
||||
provide an additional ID in their clock property. The values of this
|
||||
ID are documented in sunxi/<soc>-gates.txt.
|
||||
provide an additional ID in their clock property. This ID is the
|
||||
offset of the bit controlling this particular gate in the register.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
@ -1,93 +0,0 @@
|
|||
Gate clock outputs
|
||||
------------------
|
||||
|
||||
* AXI gates ("allwinner,sun4i-axi-gates-clk")
|
||||
|
||||
DRAM 0
|
||||
|
||||
* AHB gates ("allwinner,sun4i-ahb-gates-clk")
|
||||
|
||||
USB0 0
|
||||
EHCI0 1
|
||||
OHCI0 2*
|
||||
EHCI1 3
|
||||
OHCI1 4*
|
||||
SS 5
|
||||
DMA 6
|
||||
BIST 7
|
||||
MMC0 8
|
||||
MMC1 9
|
||||
MMC2 10
|
||||
MMC3 11
|
||||
MS 12**
|
||||
NAND 13
|
||||
SDRAM 14
|
||||
|
||||
ACE 16
|
||||
EMAC 17
|
||||
TS 18
|
||||
|
||||
SPI0 20
|
||||
SPI1 21
|
||||
SPI2 22
|
||||
SPI3 23
|
||||
PATA 24
|
||||
SATA 25**
|
||||
GPS 26*
|
||||
|
||||
VE 32
|
||||
TVD 33
|
||||
TVE0 34
|
||||
TVE1 35
|
||||
LCD0 36
|
||||
LCD1 37
|
||||
|
||||
CSI0 40
|
||||
CSI1 41
|
||||
|
||||
HDMI 43
|
||||
DE_BE0 44
|
||||
DE_BE1 45
|
||||
DE_FE1 46
|
||||
DE_FE1 47
|
||||
|
||||
MP 50
|
||||
|
||||
MALI400 52
|
||||
|
||||
* APB0 gates ("allwinner,sun4i-apb0-gates-clk")
|
||||
|
||||
CODEC 0
|
||||
SPDIF 1*
|
||||
AC97 2
|
||||
IIS 3
|
||||
|
||||
PIO 5
|
||||
IR0 6
|
||||
IR1 7
|
||||
|
||||
KEYPAD 10
|
||||
|
||||
* APB1 gates ("allwinner,sun4i-apb1-gates-clk")
|
||||
|
||||
I2C0 0
|
||||
I2C1 1
|
||||
I2C2 2
|
||||
|
||||
CAN 4
|
||||
SCR 5
|
||||
PS20 6
|
||||
PS21 7
|
||||
|
||||
UART0 16
|
||||
UART1 17
|
||||
UART2 18
|
||||
UART3 19
|
||||
UART4 20
|
||||
UART5 21
|
||||
UART6 22
|
||||
UART7 23
|
||||
|
||||
Notation:
|
||||
[*]: The datasheet didn't mention these, but they are present on AW code
|
||||
[**]: The datasheet had this marked as "NC" but they are used on AW code
|
|
@ -1,75 +0,0 @@
|
|||
Gate clock outputs
|
||||
------------------
|
||||
|
||||
* AXI gates ("allwinner,sun4i-axi-gates-clk")
|
||||
|
||||
DRAM 0
|
||||
|
||||
* AHB gates ("allwinner,sun5i-a10s-ahb-gates-clk")
|
||||
|
||||
USB0 0
|
||||
EHCI0 1
|
||||
OHCI0 2
|
||||
|
||||
SS 5
|
||||
DMA 6
|
||||
BIST 7
|
||||
MMC0 8
|
||||
MMC1 9
|
||||
MMC2 10
|
||||
|
||||
NAND 13
|
||||
SDRAM 14
|
||||
|
||||
EMAC 17
|
||||
TS 18
|
||||
|
||||
SPI0 20
|
||||
SPI1 21
|
||||
SPI2 22
|
||||
|
||||
GPS 26
|
||||
|
||||
HSTIMER 28
|
||||
|
||||
VE 32
|
||||
|
||||
TVE 34
|
||||
|
||||
LCD 36
|
||||
|
||||
CSI 40
|
||||
|
||||
HDMI 43
|
||||
DE_BE 44
|
||||
|
||||
DE_FE 46
|
||||
|
||||
IEP 51
|
||||
MALI400 52
|
||||
|
||||
* APB0 gates ("allwinner,sun5i-a10s-apb0-gates-clk")
|
||||
|
||||
CODEC 0
|
||||
|
||||
IIS 3
|
||||
|
||||
PIO 5
|
||||
IR 6
|
||||
|
||||
KEYPAD 10
|
||||
|
||||
* APB1 gates ("allwinner,sun5i-a10s-apb1-gates-clk")
|
||||
|
||||
I2C0 0
|
||||
I2C1 1
|
||||
I2C2 2
|
||||
|
||||
UART0 16
|
||||
UART1 17
|
||||
UART2 18
|
||||
UART3 19
|
||||
|
||||
Notation:
|
||||
[*]: The datasheet didn't mention these, but they are present on AW code
|
||||
[**]: The datasheet had this marked as "NC" but they are used on AW code
|
|
@ -1,58 +0,0 @@
|
|||
Gate clock outputs
|
||||
------------------
|
||||
|
||||
* AXI gates ("allwinner,sun4i-axi-gates-clk")
|
||||
|
||||
DRAM 0
|
||||
|
||||
* AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
|
||||
|
||||
USBOTG 0
|
||||
EHCI 1
|
||||
OHCI 2
|
||||
|
||||
SS 5
|
||||
DMA 6
|
||||
BIST 7
|
||||
MMC0 8
|
||||
MMC1 9
|
||||
MMC2 10
|
||||
|
||||
NAND 13
|
||||
SDRAM 14
|
||||
|
||||
SPI0 20
|
||||
SPI1 21
|
||||
SPI2 22
|
||||
|
||||
STIMER 28
|
||||
|
||||
VE 32
|
||||
|
||||
LCD 36
|
||||
|
||||
CSI 40
|
||||
|
||||
DE_BE 44
|
||||
|
||||
DE_FE 46
|
||||
|
||||
IEP 51
|
||||
MALI400 52
|
||||
|
||||
* APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
|
||||
|
||||
CODEC 0
|
||||
|
||||
PIO 5
|
||||
IR 6
|
||||
|
||||
* APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
|
||||
|
||||
I2C0 0
|
||||
I2C1 1
|
||||
I2C2 2
|
||||
|
||||
UART1 17
|
||||
|
||||
UART3 19
|
|
@ -1,83 +0,0 @@
|
|||
Gate clock outputs
|
||||
------------------
|
||||
|
||||
* AHB1 gates ("allwinner,sun6i-a31-ahb1-gates-clk")
|
||||
|
||||
MIPI DSI 1
|
||||
|
||||
SS 5
|
||||
DMA 6
|
||||
|
||||
MMC0 8
|
||||
MMC1 9
|
||||
MMC2 10
|
||||
MMC3 11
|
||||
|
||||
NAND1 12
|
||||
NAND0 13
|
||||
SDRAM 14
|
||||
|
||||
GMAC 17
|
||||
TS 18
|
||||
HSTIMER 19
|
||||
SPI0 20
|
||||
SPI1 21
|
||||
SPI2 22
|
||||
SPI3 23
|
||||
USB_OTG 24
|
||||
|
||||
EHCI0 26
|
||||
EHCI1 27
|
||||
|
||||
OHCI0 29
|
||||
OHCI1 30
|
||||
OHCI2 31
|
||||
VE 32
|
||||
|
||||
LCD0 36
|
||||
LCD1 37
|
||||
|
||||
CSI 40
|
||||
|
||||
HDMI 43
|
||||
DE_BE0 44
|
||||
DE_BE1 45
|
||||
DE_FE1 46
|
||||
DE_FE1 47
|
||||
|
||||
MP 50
|
||||
|
||||
GPU 52
|
||||
|
||||
DEU0 55
|
||||
DEU1 56
|
||||
DRC0 57
|
||||
DRC1 58
|
||||
|
||||
* APB1 gates ("allwinner,sun6i-a31-apb1-gates-clk")
|
||||
|
||||
CODEC 0
|
||||
|
||||
DIGITAL MIC 4
|
||||
PIO 5
|
||||
|
||||
DAUDIO0 12
|
||||
DAUDIO1 13
|
||||
|
||||
* APB2 gates ("allwinner,sun6i-a31-apb2-gates-clk")
|
||||
|
||||
I2C0 0
|
||||
I2C1 1
|
||||
I2C2 2
|
||||
I2C3 3
|
||||
|
||||
UART0 16
|
||||
UART1 17
|
||||
UART2 18
|
||||
UART3 19
|
||||
UART4 20
|
||||
UART5 21
|
||||
|
||||
Notation:
|
||||
[*]: The datasheet didn't mention these, but they are present on AW code
|
||||
[**]: The datasheet had this marked as "NC" but they are used on AW code
|
|
@ -1,98 +0,0 @@
|
|||
Gate clock outputs
|
||||
------------------
|
||||
|
||||
* AXI gates ("allwinner,sun4i-axi-gates-clk")
|
||||
|
||||
DRAM 0
|
||||
|
||||
* AHB gates ("allwinner,sun7i-a20-ahb-gates-clk")
|
||||
|
||||
USB0 0
|
||||
EHCI0 1
|
||||
OHCI0 2
|
||||
EHCI1 3
|
||||
OHCI1 4
|
||||
SS 5
|
||||
DMA 6
|
||||
BIST 7
|
||||
MMC0 8
|
||||
MMC1 9
|
||||
MMC2 10
|
||||
MMC3 11
|
||||
MS 12
|
||||
NAND 13
|
||||
SDRAM 14
|
||||
|
||||
ACE 16
|
||||
EMAC 17
|
||||
TS 18
|
||||
|
||||
SPI0 20
|
||||
SPI1 21
|
||||
SPI2 22
|
||||
SPI3 23
|
||||
|
||||
SATA 25
|
||||
|
||||
HSTIMER 28
|
||||
|
||||
VE 32
|
||||
TVD 33
|
||||
TVE0 34
|
||||
TVE1 35
|
||||
LCD0 36
|
||||
LCD1 37
|
||||
|
||||
CSI0 40
|
||||
CSI1 41
|
||||
|
||||
HDMI1 42
|
||||
HDMI0 43
|
||||
DE_BE0 44
|
||||
DE_BE1 45
|
||||
DE_FE1 46
|
||||
DE_FE1 47
|
||||
|
||||
GMAC 49
|
||||
MP 50
|
||||
|
||||
MALI400 52
|
||||
|
||||
* APB0 gates ("allwinner,sun7i-a20-apb0-gates-clk")
|
||||
|
||||
CODEC 0
|
||||
SPDIF 1
|
||||
AC97 2
|
||||
IIS0 3
|
||||
IIS1 4
|
||||
PIO 5
|
||||
IR0 6
|
||||
IR1 7
|
||||
IIS2 8
|
||||
|
||||
KEYPAD 10
|
||||
|
||||
* APB1 gates ("allwinner,sun7i-a20-apb1-gates-clk")
|
||||
|
||||
I2C0 0
|
||||
I2C1 1
|
||||
I2C2 2
|
||||
I2C3 3
|
||||
CAN 4
|
||||
SCR 5
|
||||
PS20 6
|
||||
PS21 7
|
||||
|
||||
I2C4 15
|
||||
UART0 16
|
||||
UART1 17
|
||||
UART2 18
|
||||
UART3 19
|
||||
UART4 20
|
||||
UART5 21
|
||||
UART6 22
|
||||
UART7 23
|
||||
|
||||
Notation:
|
||||
[*]: The datasheet didn't mention these, but they are present on AW code
|
||||
[**]: The datasheet had this marked as "NC" but they are used on AW code
|
111
Documentation/devicetree/bindings/clock/xgene.txt
Normal file
111
Documentation/devicetree/bindings/clock/xgene.txt
Normal file
|
@ -0,0 +1,111 @@
|
|||
Device Tree Clock bindings for APM X-Gene
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
|
||||
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
|
||||
"apm,xgene-device-clock" - for a X-Gene device clock
|
||||
|
||||
Required properties for SoC or PCP PLL clocks:
|
||||
- reg : shall be the physical PLL register address for the pll clock.
|
||||
- clocks : shall be the input parent clock phandle for the clock. This should
|
||||
be the reference clock.
|
||||
- #clock-cells : shall be set to 1.
|
||||
- clock-output-names : shall be the name of the PLL referenced by derive
|
||||
clock.
|
||||
Optional properties for PLL clocks:
|
||||
- clock-names : shall be the name of the PLL. If missing, use the device name.
|
||||
|
||||
Required properties for device clocks:
|
||||
- reg : shall be a list of address and length pairs describing the CSR
|
||||
reset and/or the divider. Either may be omitted, but at least
|
||||
one must be present.
|
||||
- reg-names : shall be a string list describing the reg resource. This
|
||||
may include "csr-reg" and/or "div-reg". If this property
|
||||
is not present, the reg property is assumed to describe
|
||||
only "csr-reg".
|
||||
- clocks : shall be the input parent clock phandle for the clock.
|
||||
- #clock-cells : shall be set to 1.
|
||||
- clock-output-names : shall be the name of the device referenced.
|
||||
Optional properties for device clocks:
|
||||
- clock-names : shall be the name of the device clock. If missing, use the
|
||||
device name.
|
||||
- csr-offset : Offset to the CSR reset register from the reset address base.
|
||||
Default is 0.
|
||||
- csr-mask : CSR reset mask bit. Default is 0xF.
|
||||
- enable-offset : Offset to the enable register from the reset address base.
|
||||
Default is 0x8.
|
||||
- enable-mask : CSR enable mask bit. Default is 0xF.
|
||||
- divider-offset : Offset to the divider CSR register from the divider base.
|
||||
Default is 0x0.
|
||||
- divider-width : Width of the divider register. Default is 0.
|
||||
- divider-shift : Bit shift of the divider register. Default is 0.
|
||||
|
||||
For example:
|
||||
|
||||
pcppll: pcppll@17000100 {
|
||||
compatible = "apm,xgene-pcppll-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&refclk 0>;
|
||||
clock-names = "pcppll";
|
||||
reg = <0x0 0x17000100 0x0 0x1000>;
|
||||
clock-output-names = "pcppll";
|
||||
type = <0>;
|
||||
};
|
||||
|
||||
socpll: socpll@17000120 {
|
||||
compatible = "apm,xgene-socpll-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&refclk 0>;
|
||||
clock-names = "socpll";
|
||||
reg = <0x0 0x17000120 0x0 0x1000>;
|
||||
clock-output-names = "socpll";
|
||||
type = <1>;
|
||||
};
|
||||
|
||||
qmlclk: qmlclk {
|
||||
compatible = "apm,xgene-device-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&socplldiv2 0>;
|
||||
clock-names = "qmlclk";
|
||||
reg = <0x0 0x1703C000 0x0 0x1000>;
|
||||
reg-name = "csr-reg";
|
||||
clock-output-names = "qmlclk";
|
||||
};
|
||||
|
||||
ethclk: ethclk {
|
||||
compatible = "apm,xgene-device-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&socplldiv2 0>;
|
||||
clock-names = "ethclk";
|
||||
reg = <0x0 0x17000000 0x0 0x1000>;
|
||||
reg-names = "div-reg";
|
||||
divider-offset = <0x238>;
|
||||
divider-width = <0x9>;
|
||||
divider-shift = <0x0>;
|
||||
clock-output-names = "ethclk";
|
||||
};
|
||||
|
||||
apbclk: apbclk {
|
||||
compatible = "apm,xgene-device-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&ahbclk 0>;
|
||||
clock-names = "apbclk";
|
||||
reg = <0x0 0x1F2AC000 0x0 0x1000
|
||||
0x0 0x1F2AC000 0x0 0x1000>;
|
||||
reg-names = "csr-reg", "div-reg";
|
||||
csr-offset = <0x0>;
|
||||
csr-mask = <0x200>;
|
||||
enable-offset = <0x8>;
|
||||
enable-mask = <0x200>;
|
||||
divider-offset = <0x10>;
|
||||
divider-width = <0x2>;
|
||||
divider-shift = <0x0>;
|
||||
flags = <0x8>;
|
||||
clock-output-names = "apbclk";
|
||||
};
|
||||
|
31
Documentation/devicetree/bindings/crypto/omap-aes.txt
Normal file
31
Documentation/devicetree/bindings/crypto/omap-aes.txt
Normal file
|
@ -0,0 +1,31 @@
|
|||
OMAP SoC AES crypto Module
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should contain entries for this and backward compatible
|
||||
AES versions:
|
||||
- "ti,omap2-aes" for OMAP2.
|
||||
- "ti,omap3-aes" for OMAP3.
|
||||
- "ti,omap4-aes" for OMAP4 and AM33XX.
|
||||
Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
|
||||
more algorithms) but they are incompatible with OMAP4.
|
||||
- ti,hwmods: Name of the hwmod associated with the AES module
|
||||
- reg : Offset and length of the register set for the module
|
||||
- interrupts : the interrupt-specifier for the AES module.
|
||||
|
||||
Optional properties:
|
||||
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
|
||||
Documentation/devicetree/bindings/dma/dma.txt
|
||||
- dma-names: DMA request names should include "tx" and "rx" if present.
|
||||
|
||||
Example:
|
||||
/* AM335x */
|
||||
aes: aes@53500000 {
|
||||
compatible = "ti,omap4-aes";
|
||||
ti,hwmods = "aes";
|
||||
reg = <0x53500000 0xa0>;
|
||||
interrupts = <102>;
|
||||
dmas = <&edma 6>,
|
||||
<&edma 5>;
|
||||
dma-names = "tx", "rx";
|
||||
};
|
30
Documentation/devicetree/bindings/crypto/omap-des.txt
Normal file
30
Documentation/devicetree/bindings/crypto/omap-des.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
OMAP SoC DES crypto Module
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should contain "ti,omap4-des"
|
||||
- ti,hwmods: Name of the hwmod associated with the DES module
|
||||
- reg : Offset and length of the register set for the module
|
||||
- interrupts : the interrupt-specifier for the DES module
|
||||
- clocks : A phandle to the functional clock node of the DES module
|
||||
corresponding to each entry in clock-names
|
||||
- clock-names : Name of the functional clock, should be "fck"
|
||||
|
||||
Optional properties:
|
||||
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
|
||||
Documentation/devicetree/bindings/dma/dma.txt
|
||||
Each entry corresponds to an entry in dma-names
|
||||
- dma-names: DMA request names should include "tx" and "rx" if present
|
||||
|
||||
Example:
|
||||
/* DRA7xx SoC */
|
||||
des: des@480a5000 {
|
||||
compatible = "ti,omap4-des";
|
||||
ti,hwmods = "des";
|
||||
reg = <0x480a5000 0xa0>;
|
||||
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
|
||||
dmas = <&sdma 117>, <&sdma 116>;
|
||||
dma-names = "tx", "rx";
|
||||
clocks = <&l3_iclk_div>;
|
||||
clock-names = "fck";
|
||||
};
|
28
Documentation/devicetree/bindings/crypto/omap-sham.txt
Normal file
28
Documentation/devicetree/bindings/crypto/omap-sham.txt
Normal file
|
@ -0,0 +1,28 @@
|
|||
OMAP SoC SHA crypto Module
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should contain entries for this and backward compatible
|
||||
SHAM versions:
|
||||
- "ti,omap2-sham" for OMAP2 & OMAP3.
|
||||
- "ti,omap4-sham" for OMAP4 and AM33XX.
|
||||
- "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
|
||||
- ti,hwmods: Name of the hwmod associated with the SHAM module
|
||||
- reg : Offset and length of the register set for the module
|
||||
- interrupts : the interrupt-specifier for the SHAM module.
|
||||
|
||||
Optional properties:
|
||||
- dmas: DMA specifiers for the rx dma. See the DMA client binding,
|
||||
Documentation/devicetree/bindings/dma/dma.txt
|
||||
- dma-names: DMA request name. Should be "rx" if a dma is present.
|
||||
|
||||
Example:
|
||||
/* AM335x */
|
||||
sham: sham@53100000 {
|
||||
compatible = "ti,omap4-sham";
|
||||
ti,hwmods = "sham";
|
||||
reg = <0x53100000 0x200>;
|
||||
interrupts = <109>;
|
||||
dmas = <&edma 36>;
|
||||
dma-names = "rx";
|
||||
};
|
36
Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
Normal file
36
Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
Normal file
|
@ -0,0 +1,36 @@
|
|||
* Abilis TB10x GPIO controller
|
||||
|
||||
Required Properties:
|
||||
- compatible: Should be "abilis,tb10x-gpio"
|
||||
- reg: Address and length of the register set for the device
|
||||
- gpio-controller: Marks the device node as a gpio controller.
|
||||
- #gpio-cells: Should be <2>. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted).
|
||||
- abilis,ngpio: the number of GPIO pins this driver controls.
|
||||
|
||||
Optional Properties:
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells: Should be <1>. Interrupts are triggered on both edges.
|
||||
- interrupts: Defines the interrupt line connecting this GPIO controller to
|
||||
its parent interrupt controller.
|
||||
- interrupt-parent: Defines the parent interrupt controller.
|
||||
|
||||
GPIO ranges are specified as described in
|
||||
Documentation/devicetree/bindings/gpio/gpio.txt
|
||||
|
||||
Example:
|
||||
|
||||
gpioa: gpio@FF140000 {
|
||||
compatible = "abilis,tb10x-gpio";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF140000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
abilis,ngpio = <3>;
|
||||
gpio-ranges = <&iomux 0 0 0>;
|
||||
gpio-ranges-group-names = "gpioa_pins";
|
||||
};
|
52
Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
Normal file
52
Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
Normal file
|
@ -0,0 +1,52 @@
|
|||
Broadcom Kona Family GPIO
|
||||
=========================
|
||||
|
||||
This GPIO driver is used in the following Broadcom SoCs:
|
||||
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
|
||||
|
||||
The Broadcom GPIO Controller IP can be configured prior to synthesis to
|
||||
support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
|
||||
GPIO controller only supports edge, not level, triggering of interrupts.
|
||||
|
||||
Required properties
|
||||
-------------------
|
||||
|
||||
- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller. There is one GPIO
|
||||
interrupt per GPIO bank. The number of interrupts listed depends on the
|
||||
number of GPIO banks on the SoC. The interrupts must be ordered by bank,
|
||||
starting with bank 0. There is always a 1:1 mapping between banks and
|
||||
IRQs.
|
||||
- #gpio-cells: Should be <2>. The first cell is the pin number, the second
|
||||
cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||
See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
|
||||
- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
|
||||
second cell is used to specify flags. The following subset of flags is
|
||||
supported:
|
||||
- trigger type (bits[1:0]):
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
3 = low-to-high or high-to-low edge triggered
|
||||
Valid values are 1, 2, 3
|
||||
See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
|
||||
Example:
|
||||
gpio: gpio@35003000 {
|
||||
compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
|
||||
reg = <0x35003000 0x800>;
|
||||
interrupts =
|
||||
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
|
||||
GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
|
||||
GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
|
||||
GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
|
||||
GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
|
||||
GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
};
|
71
Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Normal file
71
Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Normal file
|
@ -0,0 +1,71 @@
|
|||
* PCF857x-compatible I/O expanders
|
||||
|
||||
The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
|
||||
driven high by a pull-up current source or driven low to ground. This combines
|
||||
the direction and output level into a single bit per line, which can't be read
|
||||
back. We can't actually know at initialization time whether a line is configured
|
||||
(a) as output and driving the signal low/high, or (b) as input and reporting a
|
||||
low/high value, without knowing the last value written since the chip came out
|
||||
of reset (if any). The only reliable solution for setting up line direction is
|
||||
thus to do it explicitly.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "maxim,max7328": For the Maxim MAX7378
|
||||
- "maxim,max7329": For the Maxim MAX7329
|
||||
- "nxp,pca8574": For the NXP PCA8574
|
||||
- "nxp,pca8575": For the NXP PCA8575
|
||||
- "nxp,pca9670": For the NXP PCA9670
|
||||
- "nxp,pca9671": For the NXP PCA9671
|
||||
- "nxp,pca9672": For the NXP PCA9672
|
||||
- "nxp,pca9673": For the NXP PCA9673
|
||||
- "nxp,pca9674": For the NXP PCA9674
|
||||
- "nxp,pca9675": For the NXP PCA9675
|
||||
- "nxp,pcf8574": For the NXP PCF8574
|
||||
- "nxp,pcf8574a": For the NXP PCF8574A
|
||||
- "nxp,pcf8575": For the NXP PCF8575
|
||||
- "ti,tca9554": For the TI TCA9554
|
||||
|
||||
- reg: I2C slave address.
|
||||
|
||||
- gpio-controller: Marks the device node as a gpio controller.
|
||||
- #gpio-cells: Should be 2. The first cell is the GPIO number and the second
|
||||
cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
|
||||
GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- lines-initial-states: Bitmask that specifies the initial state of each
|
||||
line. When a bit is set to zero, the corresponding line will be initialized to
|
||||
the input (pulled-up) state. When the bit is set to one, the line will be
|
||||
initialized the the low-level output state. If the property is not specified
|
||||
all lines will be initialized to the input state.
|
||||
|
||||
The I/O expander can detect input state changes, and thus optionally act as
|
||||
an interrupt controller. When the expander interrupt line is connected all the
|
||||
following properties must be set. For more information please see the
|
||||
interrupt controller device tree bindings documentation available at
|
||||
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
|
||||
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
- interrupts: Interrupt specifier for the controllers interrupt.
|
||||
|
||||
|
||||
Please refer to gpio.txt in this directory for details of the common GPIO
|
||||
bindings used by client devices.
|
||||
|
||||
Example: PCF8575 I/O expander node
|
||||
|
||||
pcf8575: gpio@20 {
|
||||
compatible = "nxp,pcf8575";
|
||||
reg = <0x20>;
|
||||
interrupt-parent = <&irqpin2>;
|
||||
interrupts = <3 0>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
|
@ -87,8 +87,10 @@ controllers. The gpio-ranges property described below represents this, and
|
|||
contains information structures as follows:
|
||||
|
||||
gpio-range-list ::= <single-gpio-range> [gpio-range-list]
|
||||
single-gpio-range ::=
|
||||
single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range>
|
||||
numeric-gpio-range ::=
|
||||
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
|
||||
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
|
||||
gpio-phandle : phandle to pin controller node.
|
||||
gpio-base : Base GPIO ID in the GPIO controller
|
||||
pinctrl-base : Base pinctrl pin ID in the pin controller
|
||||
|
@ -97,6 +99,19 @@ contains information structures as follows:
|
|||
The "pin controller node" mentioned above must conform to the bindings
|
||||
described in ../pinctrl/pinctrl-bindings.txt.
|
||||
|
||||
In case named gpio ranges are used (ranges with both <pinctrl-base> and
|
||||
<count> set to 0), the property gpio-ranges-group-names contains one string
|
||||
for every single-gpio-range in gpio-ranges:
|
||||
gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list]
|
||||
gpiorange-name : Name of the pingroup associated to the GPIO range in
|
||||
the respective pin controller.
|
||||
|
||||
Elements of gpiorange-names-list corresponding to numeric ranges contain
|
||||
the empty string. Elements of gpiorange-names-list corresponding to named
|
||||
ranges contain the name of a pin group defined in the respective pin
|
||||
controller. The number of pins/GPIOs in the range is the number of pins in
|
||||
that pin group.
|
||||
|
||||
Previous versions of this binding required all pin controller nodes that
|
||||
were referenced by any gpio-ranges property to contain a property named
|
||||
#gpio-range-cells with value <3>. This requirement is now deprecated.
|
||||
|
@ -104,7 +119,7 @@ However, that property may still exist in older device trees for
|
|||
compatibility reasons, and would still be required even in new device
|
||||
trees that need to be compatible with older software.
|
||||
|
||||
Example:
|
||||
Example 1:
|
||||
|
||||
qe_pio_e: gpio-controller@1460 {
|
||||
#gpio-cells = <2>;
|
||||
|
@ -117,3 +132,24 @@ Example:
|
|||
Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
|
||||
pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
|
||||
pins 50..59.
|
||||
|
||||
Example 2:
|
||||
|
||||
gpio_pio_i: gpio-controller@14B0 {
|
||||
#gpio-cells = <2>;
|
||||
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
||||
reg = <0x1480 0x18>;
|
||||
gpio-controller;
|
||||
gpio-ranges = <&pinctrl1 0 20 10>,
|
||||
<&pinctrl2 10 0 0>,
|
||||
<&pinctrl1 15 0 10>,
|
||||
<&pinctrl2 25 0 0>;
|
||||
gpio-ranges-group-names = "",
|
||||
"foo",
|
||||
"",
|
||||
"bar";
|
||||
};
|
||||
|
||||
Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
|
||||
ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
|
||||
are named "foo" and "bar".
|
||||
|
|
44
Documentation/devicetree/bindings/hwmon/lm90.txt
Normal file
44
Documentation/devicetree/bindings/hwmon/lm90.txt
Normal file
|
@ -0,0 +1,44 @@
|
|||
* LM90 series thermometer.
|
||||
|
||||
Required node properties:
|
||||
- compatible: manufacturer and chip name, one of
|
||||
"adi,adm1032"
|
||||
"adi,adt7461"
|
||||
"adi,adt7461a"
|
||||
"gmt,g781"
|
||||
"national,lm90"
|
||||
"national,lm86"
|
||||
"national,lm89"
|
||||
"national,lm99"
|
||||
"dallas,max6646"
|
||||
"dallas,max6647"
|
||||
"dallas,max6649"
|
||||
"dallas,max6657"
|
||||
"dallas,max6658"
|
||||
"dallas,max6659"
|
||||
"dallas,max6680"
|
||||
"dallas,max6681"
|
||||
"dallas,max6695"
|
||||
"dallas,max6696"
|
||||
"onnn,nct1008"
|
||||
"winbond,w83l771"
|
||||
"nxp,sa56004"
|
||||
|
||||
- reg: I2C bus address of the device
|
||||
|
||||
- vcc-supply: vcc regulator for the supply voltage.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: Contains a single interrupt specifier which describes the
|
||||
LM90 "-ALERT" pin output.
|
||||
See interrupt-controller/interrupts.txt for the format.
|
||||
|
||||
Example LM90 node:
|
||||
|
||||
temp-sensor {
|
||||
compatible = "onnn,nct1008";
|
||||
reg = <0x4c>;
|
||||
vcc-supply = <&palmas_ldo6_reg>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
|
||||
}
|
22
Documentation/devicetree/bindings/hwrng/omap_rng.txt
Normal file
22
Documentation/devicetree/bindings/hwrng/omap_rng.txt
Normal file
|
@ -0,0 +1,22 @@
|
|||
OMAP SoC HWRNG Module
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should contain entries for this and backward compatible
|
||||
RNG versions:
|
||||
- "ti,omap2-rng" for OMAP2.
|
||||
- "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
|
||||
Note that these two versions are incompatible.
|
||||
- ti,hwmods: Name of the hwmod associated with the RNG module
|
||||
- reg : Offset and length of the register set for the module
|
||||
- interrupts : the interrupt number for the RNG module.
|
||||
Only used for "ti,omap4-rng".
|
||||
|
||||
Example:
|
||||
/* AM335x */
|
||||
rng: rng@48310000 {
|
||||
compatible = "ti,omap4-rng";
|
||||
ti,hwmods = "rng";
|
||||
reg = <0x48310000 0x2000>;
|
||||
interrupts = <111>;
|
||||
};
|
35
Documentation/devicetree/bindings/i2c/i2c-bcm-kona.txt
Normal file
35
Documentation/devicetree/bindings/i2c/i2c-bcm-kona.txt
Normal file
|
@ -0,0 +1,35 @@
|
|||
Broadcom Kona Family I2C
|
||||
=========================
|
||||
|
||||
This I2C controller is used in the following Broadcom SoCs:
|
||||
|
||||
BCM11130
|
||||
BCM11140
|
||||
BCM11351
|
||||
BCM28145
|
||||
BCM28155
|
||||
|
||||
Required Properties
|
||||
-------------------
|
||||
- compatible: "brcm,bcm11351-i2c", "brcm,kona-i2c"
|
||||
- reg: Physical base address and length of controller registers
|
||||
- interrupts: The interrupt number used by the controller
|
||||
- clocks: clock specifier for the kona i2c external clock
|
||||
- clock-frequency: The I2C bus frequency in Hz
|
||||
- #address-cells: Should be <1>
|
||||
- #size-cells: Should be <0>
|
||||
|
||||
Refer to clocks/clock-bindings.txt for generic clock consumer
|
||||
properties.
|
||||
|
||||
Example:
|
||||
|
||||
i2c@3e016000 {
|
||||
compatible = "brcm,bcm11351-i2c","brcm,kona-i2c";
|
||||
reg = <0x3e016000 0x80>;
|
||||
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&bsc1_clk>;
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
44
Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
Normal file
44
Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
Normal file
|
@ -0,0 +1,44 @@
|
|||
* Samsung's High Speed I2C controller
|
||||
|
||||
The Samsung's High Speed I2C controller is used to interface with I2C devices
|
||||
at various speeds ranging from 100khz to 3.4Mhz.
|
||||
|
||||
Required properties:
|
||||
- compatible: value should be.
|
||||
-> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
- #address-cells: always 1 (for i2c addresses)
|
||||
- #size-cells: always 0
|
||||
|
||||
- Pinctrl:
|
||||
- pinctrl-0: Pin control group to be used for this controller.
|
||||
- pinctrl-names: Should contain only one value - "default".
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: Desired operating frequency in Hz of the bus.
|
||||
-> If not specified, the bus operates in fast-speed mode at
|
||||
at 100khz.
|
||||
-> If specified, the bus operates in high-speed mode only if the
|
||||
clock-frequency is >= 1Mhz.
|
||||
|
||||
Example:
|
||||
|
||||
hsi2c@12ca0000 {
|
||||
compatible = "samsung,exynos5-hsi2c";
|
||||
reg = <0x12ca0000 0x100>;
|
||||
interrupts = <56>;
|
||||
clock-frequency = <100000>;
|
||||
|
||||
pinctrl-0 = <&i2c4_bus>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
s2mps11_pmic@66 {
|
||||
compatible = "samsung,s2mps11-pmic";
|
||||
reg = <0x66>;
|
||||
};
|
||||
};
|
23
Documentation/devicetree/bindings/i2c/i2c-rcar.txt
Normal file
23
Documentation/devicetree/bindings/i2c/i2c-rcar.txt
Normal file
|
@ -0,0 +1,23 @@
|
|||
I2C for R-Car platforms
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of
|
||||
"renesas,i2c-rcar"
|
||||
"renesas,i2c-r8a7778"
|
||||
"renesas,i2c-r8a7779"
|
||||
"renesas,i2c-r8a7790"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt specifier.
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this
|
||||
propoerty indicates the default frequency 100 kHz.
|
||||
|
||||
Examples :
|
||||
|
||||
i2c0: i2c@e6500000 {
|
||||
compatible = "renesas,i2c-rcar-h2";
|
||||
reg = <0 0xe6500000 0 0x428>;
|
||||
interrupts = <0 174 0x4>;
|
||||
};
|
41
Documentation/devicetree/bindings/i2c/i2c-st.txt
Normal file
41
Documentation/devicetree/bindings/i2c/i2c-st.txt
Normal file
|
@ -0,0 +1,41 @@
|
|||
ST SSC binding, for I2C mode operation
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "st,comms-ssc-i2c" or "st,comms-ssc4-i2c"
|
||||
- reg : Offset and length of the register set for the device
|
||||
- interrupts : the interrupt specifier
|
||||
- clock-names: Must contain "ssc".
|
||||
- clocks: Must contain an entry for each name in clock-names. See the common
|
||||
clock bindings.
|
||||
- A pinctrl state named "default" must be defined to set pins in mode of
|
||||
operation for I2C transfer.
|
||||
|
||||
Optional properties :
|
||||
- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
|
||||
the default 100 kHz frequency will be used. As only Normal and Fast modes
|
||||
are supported, possible values are 100000 and 400000.
|
||||
- st,i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
|
||||
allowed through the deglitch circuit. In units of us.
|
||||
- st,i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
|
||||
allowed through the deglitch circuit. In units of us.
|
||||
- A pinctrl state named "idle" could be defined to set pins in idle state
|
||||
when I2C instance is not performing a transfer.
|
||||
- A pinctrl state named "sleep" could be defined to set pins in sleep state
|
||||
when driver enters in suspend.
|
||||
|
||||
|
||||
|
||||
Example :
|
||||
|
||||
i2c0: i2c@fed40000 {
|
||||
compatible = "st,comms-ssc4-i2c";
|
||||
reg = <0xfed40000 0x110>;
|
||||
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&CLK_S_ICN_REG_0>;
|
||||
clock-names = "ssc";
|
||||
clock-frequency = <400000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c0_default>;
|
||||
st,i2c-min-scl-pulse-width-us = <0>;
|
||||
st,i2c-min-sda-pulse-width-us = <5>;
|
||||
};
|
26
Documentation/devicetree/bindings/iio/light/cm36651.txt
Normal file
26
Documentation/devicetree/bindings/iio/light/cm36651.txt
Normal file
|
@ -0,0 +1,26 @@
|
|||
* Capella CM36651 I2C Proximity and Color Light sensor
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "capella,cm36651"
|
||||
- reg: the I2C address of the device
|
||||
- interrupts: interrupt-specifier for the sole interrupt
|
||||
generated by the device
|
||||
- vled-supply: regulator for the IR LED. IR_LED is a part
|
||||
of the cm36651 for proximity detection.
|
||||
As covered in ../../regulator/regulator.txt
|
||||
|
||||
Example:
|
||||
|
||||
i2c_cm36651: i2c-gpio {
|
||||
/* ... */
|
||||
|
||||
cm36651@18 {
|
||||
compatible = "capella,cm36651";
|
||||
reg = <0x18>;
|
||||
interrupt-parent = <&gpx0>;
|
||||
interrupts = <2 0>;
|
||||
vled-supply = <&ps_als_reg>;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
21
Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
Normal file
21
Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
* Sharp GP2AP020A00F I2C Proximity/ALS sensor
|
||||
|
||||
The proximity detector sensor requires power supply
|
||||
for its built-in led. It is also defined by this binding.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "sharp,gp2ap020a00f"
|
||||
- reg : the I2C slave address of the light sensor
|
||||
- interrupts : interrupt specifier for the sole interrupt generated
|
||||
by the device
|
||||
- vled-supply : VLED power supply, as covered in ../regulator/regulator.txt
|
||||
|
||||
Example:
|
||||
|
||||
gp2ap020a00f@39 {
|
||||
compatible = "sharp,gp2ap020a00f";
|
||||
reg = <0x39>;
|
||||
interrupts = <2 0>;
|
||||
vled-supply = <...>;
|
||||
};
|
|
@ -6,7 +6,7 @@ Required properties:
|
|||
ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
|
||||
support on the platform.
|
||||
ti,x-plate-resistance: X plate resistance
|
||||
ti,coordiante-readouts: The sequencer supports a total of 16
|
||||
ti,coordinate-readouts: The sequencer supports a total of 16
|
||||
programmable steps each step is used to
|
||||
read a single coordinate. A single
|
||||
readout is enough but multiple reads can
|
||||
|
|
|
@ -8,9 +8,6 @@ Required properties:
|
|||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The value shall be 1.
|
||||
|
||||
For the valid interrupt sources for your SoC, see the documentation in
|
||||
sunxi/<soc>.txt
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller {
|
||||
|
|
|
@ -4,16 +4,33 @@ Specifying interrupt information for devices
|
|||
1) Interrupt client nodes
|
||||
-------------------------
|
||||
|
||||
Nodes that describe devices which generate interrupts must contain an
|
||||
"interrupts" property. This property must contain a list of interrupt
|
||||
specifiers, one per output interrupt. The format of the interrupt specifier is
|
||||
determined by the interrupt controller to which the interrupts are routed; see
|
||||
section 2 below for details.
|
||||
Nodes that describe devices which generate interrupts must contain an either an
|
||||
"interrupts" property or an "interrupts-extended" property. These properties
|
||||
contain a list of interrupt specifiers, one per output interrupt. The format of
|
||||
the interrupt specifier is determined by the interrupt controller to which the
|
||||
interrupts are routed; see section 2 below for details.
|
||||
|
||||
Example:
|
||||
interrupt-parent = <&intc1>;
|
||||
interrupts = <5 0>, <6 0>;
|
||||
|
||||
The "interrupt-parent" property is used to specify the controller to which
|
||||
interrupts are routed and contains a single phandle referring to the interrupt
|
||||
controller node. This property is inherited, so it may be specified in an
|
||||
interrupt client node or in any of its parent nodes.
|
||||
interrupt client node or in any of its parent nodes. Interrupts listed in the
|
||||
"interrupts" property are always in reference to the node's interrupt parent.
|
||||
|
||||
The "interrupts-extended" property is a special form for use when a node needs
|
||||
to reference multiple interrupt parents. Each entry in this property contains
|
||||
both the parent phandle and the interrupt specifier. "interrupts-extended"
|
||||
should only be used when a device has multiple interrupt parents.
|
||||
|
||||
Example:
|
||||
interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;
|
||||
|
||||
A device node may contain either "interrupts" or "interrupts-extended", but not
|
||||
both. If both properties are present, then the operating system should log an
|
||||
error and use only the data in "interrupts".
|
||||
|
||||
2) Interrupt controller nodes
|
||||
-----------------------------
|
||||
|
|
|
@ -1,89 +0,0 @@
|
|||
Allwinner A10 (sun4i) interrupt sources
|
||||
---------------------------------------
|
||||
|
||||
The interrupt sources available for the Allwinner A10 SoC are the
|
||||
following one:
|
||||
|
||||
0: ENMI
|
||||
1: UART0
|
||||
2: UART1
|
||||
3: UART2
|
||||
4: UART3
|
||||
5: IR0
|
||||
6: IR1
|
||||
7: I2C0
|
||||
8: I2C1
|
||||
9: I2C2
|
||||
10: SPI0
|
||||
11: SPI1
|
||||
12: SPI2
|
||||
13: SPDIF
|
||||
14: AC97
|
||||
15: TS
|
||||
16: I2S
|
||||
17: UART4
|
||||
18: UART5
|
||||
19: UART6
|
||||
20: UART7
|
||||
21: KEYPAD
|
||||
22: TIMER0
|
||||
23: TIMER1
|
||||
24: TIMER2
|
||||
25: TIMER3
|
||||
26: CAN
|
||||
27: DMA
|
||||
28: PIO
|
||||
29: TOUCH_PANEL
|
||||
30: AUDIO_CODEC
|
||||
31: LRADC
|
||||
32: MMC0
|
||||
33: MMC1
|
||||
34: MMC2
|
||||
35: MMC3
|
||||
36: MEMSTICK
|
||||
37: NAND
|
||||
38: USB0
|
||||
39: USB1
|
||||
40: USB2
|
||||
41: SCR
|
||||
42: CSI0
|
||||
43: CSI1
|
||||
44: LCDCTRL0
|
||||
45: LCDCTRL1
|
||||
46: MP
|
||||
47: DEFEBE0
|
||||
48: DEFEBE1
|
||||
49: PMU
|
||||
50: SPI3
|
||||
51: TZASC
|
||||
52: PATA
|
||||
53: VE
|
||||
54: SS
|
||||
55: EMAC
|
||||
56: SATA
|
||||
57: GPS
|
||||
58: HDMI
|
||||
59: TVE
|
||||
60: ACE
|
||||
61: TVD
|
||||
62: PS2_0
|
||||
63: PS2_1
|
||||
64: USB3
|
||||
65: USB4
|
||||
66: PLE_PFM
|
||||
67: TIMER4
|
||||
68: TIMER5
|
||||
69: GPU_GP
|
||||
70: GPU_GPMMU
|
||||
71: GPU_PP0
|
||||
72: GPU_PPMMU0
|
||||
73: GPU_PMU
|
||||
74: GPU_RSV0
|
||||
75: GPU_RSV1
|
||||
76: GPU_RSV2
|
||||
77: GPU_RSV3
|
||||
78: GPU_RSV4
|
||||
79: GPU_RSV5
|
||||
80: GPU_RSV6
|
||||
82: SYNC_TIMER0
|
||||
83: SYNC_TIMER1
|
|
@ -1,55 +0,0 @@
|
|||
Allwinner A13 (sun5i) interrupt sources
|
||||
---------------------------------------
|
||||
|
||||
The interrupt sources available for the Allwinner A13 SoC are the
|
||||
following one:
|
||||
|
||||
0: ENMI
|
||||
2: UART1
|
||||
4: UART3
|
||||
5: IR
|
||||
7: I2C0
|
||||
8: I2C1
|
||||
9: I2C2
|
||||
10: SPI0
|
||||
11: SPI1
|
||||
12: SPI2
|
||||
22: TIMER0
|
||||
23: TIMER1
|
||||
24: TIMER2
|
||||
25: TIMER3
|
||||
27: DMA
|
||||
28: PIO
|
||||
29: TOUCH_PANEL
|
||||
30: AUDIO_CODEC
|
||||
31: LRADC
|
||||
32: MMC0
|
||||
33: MMC1
|
||||
34: MMC2
|
||||
37: NAND
|
||||
38: USB OTG
|
||||
39: USB EHCI
|
||||
40: USB OHCI
|
||||
42: CSI
|
||||
44: LCDCTRL
|
||||
47: DEFEBE
|
||||
49: PMU
|
||||
53: VE
|
||||
54: SS
|
||||
66: PLE_PFM
|
||||
67: TIMER4
|
||||
68: TIMER5
|
||||
69: GPU_GP
|
||||
70: GPU_GPMMU
|
||||
71: GPU_PP0
|
||||
72: GPU_PPMMU0
|
||||
73: GPU_PMU
|
||||
74: GPU_RSV0
|
||||
75: GPU_RSV1
|
||||
76: GPU_RSV2
|
||||
77: GPU_RSV3
|
||||
78: GPU_RSV4
|
||||
79: GPU_RSV5
|
||||
80: GPU_RSV6
|
||||
82: SYNC_TIMER0
|
||||
83: SYNC_TIMER1
|
|
@ -10,6 +10,7 @@ Each child has own specific current settings
|
|||
- max-cur: Maximun current at each led channel.
|
||||
|
||||
Optional properties:
|
||||
- enable-gpio: GPIO attached to the chip's enable pin
|
||||
- label: Used for naming LEDs
|
||||
- pwr-sel: LP8501 specific property. Power selection for output channels.
|
||||
0: D1~9 are connected to VDD
|
||||
|
@ -17,12 +18,15 @@ Optional properties:
|
|||
2: D1~6 with VOUT, D7~9 with VDD
|
||||
3: D1~9 are connected to VOUT
|
||||
|
||||
Alternatively, each child can have specific channel name
|
||||
- chan-name: Name of each channel name
|
||||
Alternatively, each child can have a specific channel name and trigger:
|
||||
- chan-name (optional): name of channel
|
||||
- linux,default-trigger (optional): see
|
||||
Documentation/devicetree/bindings/leds/common.txt
|
||||
|
||||
example 1) LP5521
|
||||
3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
|
||||
'lp5521_pri:channel1' and 'lp5521_pri:channel2'
|
||||
'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
|
||||
on channel 0.
|
||||
|
||||
lp5521@32 {
|
||||
compatible = "national,lp5521";
|
||||
|
@ -33,6 +37,7 @@ lp5521@32 {
|
|||
chan0 {
|
||||
led-cur = /bits/ 8 <0x2f>;
|
||||
max-cur = /bits/ 8 <0x5f>;
|
||||
linux,default-trigger = "heartbeat";
|
||||
};
|
||||
|
||||
chan1 {
|
||||
|
|
29
Documentation/devicetree/bindings/media/st-rc.txt
Normal file
29
Documentation/devicetree/bindings/media/st-rc.txt
Normal file
|
@ -0,0 +1,29 @@
|
|||
Device-Tree bindings for ST IRB IP
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain "st,comms-irb".
|
||||
- reg: Base physical address of the controller and length of memory
|
||||
mapped region.
|
||||
- interrupts: interrupt-specifier for the sole interrupt generated by
|
||||
the device. The interrupt specifier format depends on the interrupt
|
||||
controller parent.
|
||||
- rx-mode: can be "infrared" or "uhf". This property specifies the L1
|
||||
protocol used for receiving remote control signals. rx-mode should
|
||||
be present iff the rx pins are wired up.
|
||||
- tx-mode: should be "infrared". This property specifies the L1
|
||||
protocol used for transmitting remote control signals. tx-mode should
|
||||
be present iff the tx pins are wired up.
|
||||
|
||||
Optional properties:
|
||||
- pinctrl-names, pinctrl-0: the pincontrol settings to configure muxing
|
||||
properly for IRB pins.
|
||||
- clocks : phandle with clock-specifier pair for IRB.
|
||||
|
||||
Example node:
|
||||
|
||||
rc: rc@fe518000 {
|
||||
compatible = "st,comms-irb";
|
||||
reg = <0xfe518000 0x234>;
|
||||
interrupts = <0 203 0>;
|
||||
rx-mode = "infrared";
|
||||
};
|
|
@ -1,168 +0,0 @@
|
|||
*** Memory binding ***
|
||||
|
||||
The /memory node provides basic information about the address and size
|
||||
of the physical memory. This node is usually filled or updated by the
|
||||
bootloader, depending on the actual memory configuration of the given
|
||||
hardware.
|
||||
|
||||
The memory layout is described by the following node:
|
||||
|
||||
/ {
|
||||
#address-cells = <(n)>;
|
||||
#size-cells = <(m)>;
|
||||
memory {
|
||||
device_type = "memory";
|
||||
reg = <(baseaddr1) (size1)
|
||||
(baseaddr2) (size2)
|
||||
...
|
||||
(baseaddrN) (sizeN)>;
|
||||
};
|
||||
...
|
||||
};
|
||||
|
||||
A memory node follows the typical device tree rules for "reg" property:
|
||||
n: number of cells used to store base address value
|
||||
m: number of cells used to store size value
|
||||
baseaddrX: defines a base address of the defined memory bank
|
||||
sizeX: the size of the defined memory bank
|
||||
|
||||
|
||||
More than one memory bank can be defined.
|
||||
|
||||
|
||||
*** Reserved memory regions ***
|
||||
|
||||
In /memory/reserved-memory node one can create child nodes describing
|
||||
particular reserved (excluded from normal use) memory regions. Such
|
||||
memory regions are usually designed for the special usage by various
|
||||
device drivers. A good example are contiguous memory allocations or
|
||||
memory sharing with other operating system on the same hardware board.
|
||||
Those special memory regions might depend on the board configuration and
|
||||
devices used on the target system.
|
||||
|
||||
Parameters for each memory region can be encoded into the device tree
|
||||
with the following convention:
|
||||
|
||||
[(label):] (name) {
|
||||
compatible = "linux,contiguous-memory-region", "reserved-memory-region";
|
||||
reg = <(address) (size)>;
|
||||
(linux,default-contiguous-region);
|
||||
};
|
||||
|
||||
compatible: one or more of:
|
||||
- "linux,contiguous-memory-region" - enables binding of this
|
||||
region to Contiguous Memory Allocator (special region for
|
||||
contiguous memory allocations, shared with movable system
|
||||
memory, Linux kernel-specific).
|
||||
- "reserved-memory-region" - compatibility is defined, given
|
||||
region is assigned for exclusive usage for by the respective
|
||||
devices.
|
||||
|
||||
reg: standard property defining the base address and size of
|
||||
the memory region
|
||||
|
||||
linux,default-contiguous-region: property indicating that the region
|
||||
is the default region for all contiguous memory
|
||||
allocations, Linux specific (optional)
|
||||
|
||||
It is optional to specify the base address, so if one wants to use
|
||||
autoconfiguration of the base address, '0' can be specified as a base
|
||||
address in the 'reg' property.
|
||||
|
||||
The /memory/reserved-memory node must contain the same #address-cells
|
||||
and #size-cells value as the root node.
|
||||
|
||||
|
||||
*** Device node's properties ***
|
||||
|
||||
Once regions in the /memory/reserved-memory node have been defined, they
|
||||
may be referenced by other device nodes. Bindings that wish to reference
|
||||
memory regions should explicitly document their use of the following
|
||||
property:
|
||||
|
||||
memory-region = <&phandle_to_defined_region>;
|
||||
|
||||
This property indicates that the device driver should use the memory
|
||||
region pointed by the given phandle.
|
||||
|
||||
|
||||
*** Example ***
|
||||
|
||||
This example defines a memory consisting of 4 memory banks. 3 contiguous
|
||||
regions are defined for Linux kernel, one default of all device drivers
|
||||
(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the
|
||||
framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB)
|
||||
and one for multimedia processing (labelled multimedia_mem, placed at
|
||||
0x77000000, 64MiB). 'display_mem' region is then assigned to fb@12300000
|
||||
device for DMA memory allocations (Linux kernel drivers will use CMA is
|
||||
available or dma-exclusive usage otherwise). 'multimedia_mem' is
|
||||
assigned to scaler@12500000 and codec@12600000 devices for contiguous
|
||||
memory allocations when CMA driver is enabled.
|
||||
|
||||
The reason for creating a separate region for framebuffer device is to
|
||||
match the framebuffer base address to the one configured by bootloader,
|
||||
so once Linux kernel drivers starts no glitches on the displayed boot
|
||||
logo appears. Scaller and codec drivers should share the memory
|
||||
allocations.
|
||||
|
||||
/ {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
/* ... */
|
||||
|
||||
memory {
|
||||
reg = <0x40000000 0x10000000
|
||||
0x50000000 0x10000000
|
||||
0x60000000 0x10000000
|
||||
0x70000000 0x10000000>;
|
||||
|
||||
reserved-memory {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
/*
|
||||
* global autoconfigured region for contiguous allocations
|
||||
* (used only with Contiguous Memory Allocator)
|
||||
*/
|
||||
contig_region@0 {
|
||||
compatible = "linux,contiguous-memory-region";
|
||||
reg = <0x0 0x4000000>;
|
||||
linux,default-contiguous-region;
|
||||
};
|
||||
|
||||
/*
|
||||
* special region for framebuffer
|
||||
*/
|
||||
display_region: region@78000000 {
|
||||
compatible = "linux,contiguous-memory-region", "reserved-memory-region";
|
||||
reg = <0x78000000 0x800000>;
|
||||
};
|
||||
|
||||
/*
|
||||
* special region for multimedia processing devices
|
||||
*/
|
||||
multimedia_region: region@77000000 {
|
||||
compatible = "linux,contiguous-memory-region";
|
||||
reg = <0x77000000 0x4000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* ... */
|
||||
|
||||
fb0: fb@12300000 {
|
||||
status = "okay";
|
||||
memory-region = <&display_region>;
|
||||
};
|
||||
|
||||
scaler: scaler@12500000 {
|
||||
status = "okay";
|
||||
memory-region = <&multimedia_region>;
|
||||
};
|
||||
|
||||
codec: codec@12600000 {
|
||||
status = "okay";
|
||||
memory-region = <&multimedia_region>;
|
||||
};
|
||||
};
|
194
Documentation/devicetree/bindings/mfd/as3722.txt
Normal file
194
Documentation/devicetree/bindings/mfd/as3722.txt
Normal file
|
@ -0,0 +1,194 @@
|
|||
* ams AS3722 Power management IC.
|
||||
|
||||
Required properties:
|
||||
-------------------
|
||||
- compatible: Must be "ams,as3722".
|
||||
- reg: I2C device address.
|
||||
- interrupt-controller: AS3722 has internal interrupt controller which takes the
|
||||
interrupt request from internal sub-blocks like RTC, regulators, GPIOs as well
|
||||
as external input.
|
||||
- #interrupt-cells: Should be set to 2 for IRQ number and flags.
|
||||
The first cell is the IRQ number. IRQ numbers for different interrupt source
|
||||
of AS3722 are defined at dt-bindings/mfd/as3722.h
|
||||
The second cell is the flags, encoded as the trigger masks from binding document
|
||||
interrupts.txt, using dt-bindings/irq.
|
||||
|
||||
Optional submodule and their properties:
|
||||
=======================================
|
||||
|
||||
Pinmux and GPIO:
|
||||
===============
|
||||
Device has 8 GPIO pins which can be configured as GPIO as well as the special IO
|
||||
functions.
|
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Following are properties which is needed if GPIO and pinmux functionality
|
||||
is required:
|
||||
Required properties:
|
||||
-------------------
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- #gpio-cells: Number of GPIO cells. Refer to binding document
|
||||
gpio/gpio.txt
|
||||
|
||||
Optional properties:
|
||||
--------------------
|
||||
Following properties are require if pin control setting is required
|
||||
at boot.
|
||||
- pinctrl-names: A pinctrl state named "default" be defined, using the
|
||||
bindings in pinctrl/pinctrl-binding.txt.
|
||||
- pinctrl[0...n]: Properties to contain the phandle that refer to
|
||||
different nodes of pin control settings. These nodes represents
|
||||
the pin control setting of state 0 to state n. Each of these
|
||||
nodes contains different subnodes to represents some desired
|
||||
configuration for a list of pins. This configuration can
|
||||
include the mux function to select on those pin(s), and
|
||||
various pin configuration parameters, such as pull-up,
|
||||
open drain.
|
||||
|
||||
Each subnode have following properties:
|
||||
Required properties:
|
||||
- pins: List of pins. Valid values of pins properties are:
|
||||
gpio0, gpio1, gpio2, gpio3, gpio4, gpio5,
|
||||
gpio6, gpio7
|
||||
|
||||
Optional properties:
|
||||
function, bias-disable, bias-pull-up, bias-pull-down,
|
||||
bias-high-impedance, drive-open-drain.
|
||||
|
||||
Valid values for function properties are:
|
||||
gpio, interrupt-out, gpio-in-interrupt,
|
||||
vsup-vbat-low-undebounce-out,
|
||||
vsup-vbat-low-debounce-out,
|
||||
voltage-in-standby, oc-pg-sd0, oc-pg-sd6,
|
||||
powergood-out, pwm-in, pwm-out, clk32k-out,
|
||||
watchdog-in, soft-reset-in
|
||||
|
||||
Regulators:
|
||||
===========
|
||||
Device has multiple DCDC and LDOs. The node "regulators" is require if regulator
|
||||
functionality is needed.
|
||||
|
||||
Following are properties of regulator subnode.
|
||||
|
||||
Optional properties:
|
||||
-------------------
|
||||
The input supply of regulators are the optional properties on the
|
||||
regulator node. The input supply of these regulators are provided
|
||||
through following properties:
|
||||
vsup-sd2-supply: Input supply for SD2.
|
||||
vsup-sd3-supply: Input supply for SD3.
|
||||
vsup-sd4-supply: Input supply for SD4.
|
||||
vsup-sd5-supply: Input supply for SD5.
|
||||
vin-ldo0-supply: Input supply for LDO0.
|
||||
vin-ldo1-6-supply: Input supply for LDO1 and LDO6.
|
||||
vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7.
|
||||
vin-ldo3-4-supply: Input supply for LDO3 and LDO4.
|
||||
vin-ldo9-10-supply: Input supply for LDO9 and LDO10.
|
||||
vin-ldo11-supply: Input supply for LDO11.
|
||||
|
||||
Optional sub nodes for regulators:
|
||||
---------------------------------
|
||||
The subnodes name is the name of regulator and it must be one of:
|
||||
sd[0-6], ldo[0-7], ldo[9-11]
|
||||
|
||||
Each sub-node should contain the constraints and initialization
|
||||
information for that regulator. See regulator.txt for a description
|
||||
of standard properties for these sub-nodes.
|
||||
Additional optional custom properties are listed below.
|
||||
ams,ext-control: External control of the rail. The option of
|
||||
this properties will tell which external input is
|
||||
controlling this rail. Valid values are 0, 1, 2 ad 3.
|
||||
0: There is no external control of this rail.
|
||||
1: Rail is controlled by ENABLE1 input pin.
|
||||
2: Rail is controlled by ENABLE2 input pin.
|
||||
3: Rail is controlled by ENABLE3 input pin.
|
||||
Missing this property on DT will be assume as no
|
||||
external control. The external control pin macros
|
||||
are defined @dt-bindings/mfd/as3722.h
|
||||
|
||||
ams,enable-tracking: Enable tracking with SD1, only supported
|
||||
by LDO3.
|
||||
|
||||
Example:
|
||||
--------
|
||||
#include <dt-bindings/mfd/as3722.h>
|
||||
...
|
||||
ams3722 {
|
||||
compatible = "ams,as3722";
|
||||
reg = <0x48>;
|
||||
|
||||
interrupt-parent = <&intc>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&as3722_default>;
|
||||
|
||||
as3722_default: pinmux {
|
||||
gpio0 {
|
||||
pins = "gpio0";
|
||||
function = "gpio";
|
||||
bias-pull-down;
|
||||
};
|
||||
|
||||
gpio1_2_4_7 {
|
||||
pins = "gpio1", "gpio2", "gpio4", "gpio7";
|
||||
function = "gpio";
|
||||
bias-pull-up;
|
||||
};
|
||||
|
||||
gpio5 {
|
||||
pins = "gpio5";
|
||||
function = "clk32k_out";
|
||||
};
|
||||
}
|
||||
|
||||
regulators {
|
||||
vsup-sd2-supply = <...>;
|
||||
...
|
||||
|
||||
sd0 {
|
||||
regulator-name = "vdd_cpu";
|
||||
regulator-min-microvolt = <700000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-always-on;
|
||||
ams,ext-control = <2>;
|
||||
};
|
||||
|
||||
sd1 {
|
||||
regulator-name = "vdd_core";
|
||||
regulator-min-microvolt = <700000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-always-on;
|
||||
ams,ext-control = <1>;
|
||||
};
|
||||
|
||||
sd2 {
|
||||
regulator-name = "vddio_ddr";
|
||||
regulator-min-microvolt = <1350000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
sd4 {
|
||||
regulator-name = "avdd-hdmi-pex";
|
||||
regulator-min-microvolt = <1050000>;
|
||||
regulator-max-microvolt = <1050000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
sd5 {
|
||||
regulator-name = "vdd-1v8";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
....
|
||||
};
|
||||
};
|
|
@ -1,10 +1,10 @@
|
|||
|
||||
* Samsung S2MPS11 Voltage and Current Regulator
|
||||
|
||||
The Samsung S2MP211 is a multi-function device which includes voltage and
|
||||
The Samsung S2MPS11 is a multi-function device which includes voltage and
|
||||
current regulators, RTC, charger controller and other sub-blocks. It is
|
||||
interfaced to the host controller using a I2C interface. Each sub-block is
|
||||
addressed by the host system using different I2C slave address.
|
||||
interfaced to the host controller using an I2C interface. Each sub-block is
|
||||
addressed by the host system using different I2C slave addresses.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "samsung,s2mps11-pmic".
|
||||
|
@ -43,7 +43,8 @@ sub-node should be of the format as listed below.
|
|||
|
||||
BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly
|
||||
regulator-ramp-delay = <0> can be used for them to disable ramp delay.
|
||||
In absence of regulator-ramp-delay property, default ramp delay will be used.
|
||||
In the absence of the regulator-ramp-delay property, the default ramp
|
||||
delay will be used.
|
||||
|
||||
NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
|
||||
for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
|
||||
|
@ -58,10 +59,10 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
|
|||
as per the datasheet of s2mps11.
|
||||
|
||||
- LDOn
|
||||
- valid values for n are 1 to 28
|
||||
- valid values for n are 1 to 38
|
||||
- Example: LDO0, LD01, LDO28
|
||||
- BUCKn
|
||||
- valid values for n are 1 to 9.
|
||||
- valid values for n are 1 to 10.
|
||||
- Example: BUCK1, BUCK2, BUCK9
|
||||
|
||||
Example:
|
||||
|
|
|
@ -0,0 +1,17 @@
|
|||
Allwinner sunxi-sid
|
||||
|
||||
Required properties:
|
||||
- compatible: "allwinner,sun4i-sid" or "allwinner,sun7i-a20-sid".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Example for sun4i:
|
||||
sid@01c23800 {
|
||||
compatible = "allwinner,sun4i-sid";
|
||||
reg = <0x01c23800 0x10>
|
||||
};
|
||||
|
||||
Example for sun7i:
|
||||
sid@01c23800 {
|
||||
compatible = "allwinner,sun7i-a20-sid";
|
||||
reg = <0x01c23800 0x200>
|
||||
};
|
20
Documentation/devicetree/bindings/misc/ti,dac7512.txt
Normal file
20
Documentation/devicetree/bindings/misc/ti,dac7512.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
TI DAC7512 DEVICETREE BINDINGS
|
||||
|
||||
Required properties:
|
||||
|
||||
- "compatible" Must be set to "ti,dac7512"
|
||||
|
||||
Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
apply. In particular, "reg" and "spi-max-frequency" properties must be given.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
spi_master {
|
||||
dac7512: dac7512@0 {
|
||||
compatible = "ti,dac7512";
|
||||
reg = <0>; /* CS0 */
|
||||
spi-max-frequency = <1000000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
* Samsung Exynos specific extensions to the Synopsis Designware Mobile
|
||||
* Samsung Exynos specific extensions to the Synopsys Designware Mobile
|
||||
Storage Host Controller
|
||||
|
||||
The Synopsis designware mobile storage host controller is used to interface
|
||||
The Synopsys designware mobile storage host controller is used to interface
|
||||
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
|
||||
differences between the core Synopsis dw mshc controller properties described
|
||||
by synopsis-dw-mshc.txt and the properties used by the Samsung Exynos specific
|
||||
extensions to the Synopsis Designware Mobile Storage Host Controller.
|
||||
differences between the core Synopsys dw mshc controller properties described
|
||||
by synopsys-dw-mshc.txt and the properties used by the Samsung Exynos specific
|
||||
extensions to the Synopsys Designware Mobile Storage Host Controller.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue