apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge branches 'for-4.4/upstream-fixes', 'for-4.5/async-suspend', 'for-4.5/container-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.5/upstream' and 'for-4.5/wacom' into for-linus

Browse Source
This commit is contained in:
Jiri Kosina
2016-01-14 16:11:06 +01:00
parent 76833559eb 64bebefcf3 2cf83833fc 5d9374cf5f 6cf2e31bea 5f008c9859 73e7d63efb b71b5578a8 7775fb929d 0bbfe28ad0
commit 83f1bfd6f5
3183 changed files with 132100 additions and 81109 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/ABI/testing/sysfs-driver-st
+12
View File
@@ -0,0 +1,12 @@
What: /sys/bus/scsi/drivers/st/debug_flag
Date: October 2015
Kernel Version: ?.?
Contact: shane.seymour@hpe.com
Description:
This file allows you to turn debug output from the st driver
off if you write a '0' to the file or on if you write a '1'.
Note that debug output requires that the module be compiled
with the #define DEBUG set to a non-zero value (this is the
default). If DEBUG is set to 0 then this file will not
appear in sysfs as its presence is conditional upon debug
output support being compiled into the module.
Documentation/DMA-API.txt
-13
View File
@@ -141,19 +141,6 @@ memory back to the pool before you destroy it.
Part Ic - DMA addressing limitations
------------------------------------
int
dma_supported(struct device *dev, u64 mask)
Checks to see if the device can support DMA to the memory described by
mask.
Returns: 1 if it can and 0 if it can't.
Notes: This routine merely tests to see if the mask is possible. It
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)
Documentation/DocBook/Makefile
+1 -1
View File
@@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
include Documentation/DocBook/media/Makefile
Documentation/DocBook/drm.tmpl → Documentation/DocBook/gpu.tmpl
+116 -93
View File
@@ -2,9 +2,9 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="drmDevelopersGuide">
<book id="gpuDevelopersGuide">
<bookinfo>
<title>Linux DRM Developer's Guide</title>
<title>Linux GPU Driver Developer's Guide</title>
<authorgroup>
<author>
@@ -40,6 +40,16 @@
</address>
</affiliation>
</author>
<author>
<firstname>Lukas</firstname>
<surname>Wunner</surname>
<contrib>vga_switcheroo documentation</contrib>
<affiliation>
<address>
<email>lukas@wunner.de</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
@@ -51,6 +61,10 @@
<year>2012</year>
<holder>Laurent Pinchart</holder>
</copyright>
<copyright>
<year>2015</year>
<holder>Lukas Wunner</holder>
</copyright>
<legalnotice>
<para>
@@ -69,6 +83,13 @@
<revremark>Added extensive documentation about driver internals.
</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>2015-10-11</date>
<authorinitials>LW</authorinitials>
<revremark>Added vga_switcheroo documentation.
</revremark>
</revision>
</revhistory>
</bookinfo>
@@ -78,9 +99,9 @@
<title>DRM Core</title>
<partintro>
<para>
This first part of the DRM Developer's Guide documents core DRM code,
helper libraries for writing drivers and generic userspace interfaces
exposed by DRM drivers.
This first part of the GPU Driver Developer's Guide documents core DRM
code, helper libraries for writing drivers and generic userspace
interfaces exposed by DRM drivers.
</para>
</partintro>
@@ -138,14 +159,10 @@
<para>
At the core of every DRM driver is a <structname>drm_driver</structname>
structure. Drivers typically statically initialize a drm_driver structure,
and then pass it to one of the <function>drm_*_init()</function> functions
to register it with the DRM subsystem.
</para>
<para>
Newer drivers that no longer require a <structname>drm_bus</structname>
structure can alternatively use the low-level device initialization and
registration functions such as <function>drm_dev_alloc()</function> and
<function>drm_dev_register()</function> directly.
and then pass it to <function>drm_dev_alloc()</function> to allocate a
device instance. After the device instance is fully initialized it can be
registered (which makes it accessible from userspace) using
<function>drm_dev_register()</function>.
</para>
<para>
The <structname>drm_driver</structname> structure contains static
@@ -296,83 +313,12 @@ char *date;</synopsis>
</sect3>
</sect2>
<sect2>
<title>Device Registration</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices, respectively.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
<para>
New drivers that no longer rely on the services provided by the
<structname>drm_bus</structname> structure can call the low-level
device registration functions directly. The
<function>drm_dev_alloc()</function> function can be used to allocate
and initialize a new <structname>drm_device</structname> structure.
Drivers will typically want to perform some additional setup on this
structure, such as allocating driver-specific data and storing a
pointer to it in the DRM device's <structfield>dev_private</structfield>
field. Drivers should also set the device's unique name using the
<function>drm_dev_set_unique()</function> function. After it has been
set up a device can be registered with the DRM subsystem by calling
<function>drm_dev_register()</function>. This will cause the device to
be exposed to userspace and will call the driver's
<structfield>.load()</structfield> implementation. When a device is
removed, the DRM device can safely be unregistered and freed by calling
<function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>.
</para>
<title>Device Instance and Driver Handling</title>
!Pdrivers/gpu/drm/drm_drv.c driver instance overview
!Edrivers/gpu/drm/drm_drv.c
</sect2>
<sect2>
<title>Driver Load</title>
<para>
The <methodname>load</methodname> method is the driver and device
initialization entry point. The method is responsible for allocating and
initializing driver private data, performing resource allocation and
mapping (e.g. acquiring
clocks, mapping registers or allocating command buffers), initializing
the memory manager (<xref linkend="drm-memory-management"/>), installing
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
vertical blanking handling (<xref linkend="drm-vertical-blank"/>), mode
setting (<xref linkend="drm-mode-setting"/>) and initial output
configuration (<xref linkend="drm-kms-init"/>).
</para>
<note><para>
If compatibility is a concern (e.g. with drivers converted over from
User Mode Setting to Kernel Mode Setting), care must be taken to prevent
device initialization and control that is incompatible with currently
active userspace drivers. For instance, if user level mode setting
drivers are in use, it would be problematic to perform output discovery
&amp; configuration at load time. Likewise, if user-level drivers
unaware of memory management are in use, memory management and command
buffer setup may need to be omitted. These requirements are
driver-specific, and care needs to be taken to keep both old and new
applications and libraries working.
</para></note>
<synopsis>int (*load) (struct drm_device *, unsigned long flags);</synopsis>
<para>
The method takes two arguments, a pointer to the newly created
<structname>drm_device</structname> and flags. The flags are used to
pass the <structfield>driver_data</structfield> field of the device id
corresponding to the device passed to <function>drm_*_init()</function>.
Only PCI devices currently use this, USB and platform DRM drivers have
their <methodname>load</methodname> method called with flags to 0.
</para>
<sect3>
<title>Driver Private Data</title>
<para>
The driver private hangs off the main
<structname>drm_device</structname> structure and can be used for
tracking various device-specific bits of information, like register
offsets, command buffer status, register state for suspend/resume, etc.
At load time, a driver may simply allocate one and set
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
appropriately; it should be freed and
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
set to NULL when the driver is unloaded.
</para>
</sect3>
<sect3 id="drm-irq-registration">
<title>IRQ Registration</title>
<para>
@@ -465,6 +411,18 @@ char *date;</synopsis>
</para>
</sect3>
</sect2>
<sect2>
<title>Bus-specific Device Registration and PCI Support</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices respectively and are
only provided for historical reasons. These are all deprecated and
shouldn't be used in new drivers. Besides that there's a few
helpers for pci drivers.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
</sect2>
</sect1>
<!-- Internals: memory management -->
@@ -3646,10 +3604,11 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
conjunction with the vga_switcheroo infrastructure (see
<xref linkend="vga_switcheroo"/>). Beyond that KMS drivers should not
do any further cleanup. Only legacy UMS drivers might need to clean up
device state so that the vga console or an independent fbdev driver
could take over.
</para>
</sect2>
<sect2>
@@ -3747,11 +3706,14 @@ int num_ioctls;</synopsis>
</para></listitem>
<listitem><para>
DRM_UNLOCKED - The ioctl handler will be called without locking
the DRM global mutex
the DRM global mutex. This is the enforced default for kms drivers
(i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
any more for new drivers.
</para></listitem>
</itemizedlist>
</para>
</para>
!Edrivers/gpu/drm/drm_ioctl.c
</sect2>
</sect1>
<sect1>
@@ -3949,8 +3911,8 @@ int num_ioctls;</synopsis>
<partintro>
<para>
This second part of the DRM Developer's Guide documents driver code,
implementation details and also all the driver-specific userspace
This second part of the GPU Driver Developer's Guide documents driver
code, implementation details and also all the driver-specific userspace
interfaces. Especially since all hardware-acceleration interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
@@ -4051,6 +4013,7 @@ int num_ioctls;</synopsis>
<title>High Definition Audio</title>
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
!Idrivers/gpu/drm/i915/intel_audio.c
!Iinclude/drm/i915_component.h
</sect2>
<sect2>
<title>Panel Self Refresh PSR (PSR/SRD)</title>
@@ -4237,6 +4200,20 @@ int num_ioctls;</synopsis>
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
</sect2>
</sect1>
<sect1>
<title>GuC-based Command Submission</title>
<sect2>
<title>GuC</title>
!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
!Idrivers/gpu/drm/i915/intel_guc_loader.c
</sect2>
<sect2>
<title>GuC Client</title>
!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
!Idrivers/gpu/drm/i915/i915_guc_submission.c
</sect2>
</sect1>
<sect1>
<title> Tracing </title>
<para>
@@ -4260,4 +4237,50 @@ int num_ioctls;</synopsis>
</chapter>
!Cdrivers/gpu/drm/i915/i915_irq.c
</part>
<part id="vga_switcheroo">
<title>vga_switcheroo</title>
<partintro>
!Pdrivers/gpu/vga/vga_switcheroo.c Overview
</partintro>
<chapter id="modes_of_use">
<title>Modes of Use</title>
<sect1>
<title>Manual switching and manual power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control
</sect1>
<sect1>
<title>Driver power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control
</sect1>
</chapter>
<chapter id="pubfunctions">
<title>Public functions</title>
!Edrivers/gpu/vga/vga_switcheroo.c
</chapter>
<chapter id="pubstructures">
<title>Public structures</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops
</chapter>
<chapter id="pubconstants">
<title>Public constants</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
</chapter>
<chapter id="privstructures">
<title>Private structures</title>
!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv
!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client
</chapter>
!Cdrivers/gpu/vga/vga_switcheroo.c
!Cinclude/linux/vga_switcheroo.h
</part>
</book>
Documentation/IPMI.txt
+5 -2
View File
@@ -587,7 +587,7 @@ used to control it:
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x ifnum_to_use=n
nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>
ifnum_to_use specifies which interface the watchdog timer should use.
The default is -1, which means to pick the first one registered.
@@ -597,7 +597,9 @@ is the amount of seconds before the reset that the pre-timeout panic will
occur (if pretimeout is zero, then pretimeout will not be enabled). Note
that the pretimeout is the time before the final timeout. So if the
timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
will occur in 40 second (10 seconds before the timeout).
will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout
is the value of timeout which is set on kernel panic, in order to let actions
such as kdump to occur during panic.
The action may be "reset", "power_cycle", or "power_off", and
specifies what to do when the timer times out, and defaults to
@@ -634,6 +636,7 @@ for configuring the watchdog:
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
ipmi_watchdog.panic_wdt_timeout=<t>
The options are the same as the module parameter options.
Documentation/SubmittingPatches
+14 -1
View File
@@ -718,8 +718,21 @@ generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.
15) Explicit In-Reply-To headers
--------------------------------
15) Sending "git pull" requests
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
series. This way multiple versions of the patch don't become an
unmanageable forest of references in email clients. If a link is
helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in
the cover email text) to link to an earlier version of the patch series.
16) Sending "git pull" requests
-------------------------------
If you have a series of patches, it may be most convenient to have the
Documentation/acpi/i2c-muxes.txt
+58
View File
@@ -0,0 +1,58 @@
ACPI I2C Muxes
--------------
Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
Device () scope per mux channel.
Consider this topology:
+------+ +------+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+------+ +------+
which corresponds to the following ASL:
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^SMB1", 0x00,
ResourceConsumer,,)
}
Device (CH00)
{
Name (_ADR, 0)
Device (CLIA)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH00", 0x00,
ResourceConsumer,,)
}
}
}
Device (CH01)
{
Name (_ADR, 1)
Device (CLIB)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}
Documentation/arm/Samsung/Bootloader-interface.txt
+3 -2
View File
@@ -19,7 +19,7 @@ executing kernel.
Address: sysram_ns_base_addr
Offset Value Purpose
=============================================================================
0x08 exynos_cpu_resume_ns System suspend
0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend
0x0c 0x00000bad (Magic cookie) System suspend
0x1c exynos4_secondary_startup Secondary CPU boot
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
@@ -56,7 +56,8 @@ Offset Value Purpose
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
0x0908 Non-zero Secondary CPU boot up indicator
on Exynos3250 and Exynos542x
4. Glossary
Documentation/arm/keystone/Overview.txt
-18
View File
@@ -49,24 +49,6 @@ specified through DTS. Following are the DTS used:-
The device tree documentation for the keystone machines are located at
Documentation/devicetree/bindings/arm/keystone/keystone.txt
Known issues & workaround
-------------------------
Some of the device drivers used on keystone are re-used from that from
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
Some of the keystone specific drivers such as netcp uses run time power
management API instead to enable clock. As this API has limitations on
keystone, following workaround is needed to boot Linux.
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
clock frameworks will try to disable clocks that are unused and disable
the hardware. This is because netcp related power domain and clock
domains are enabled in u-boot as run time power management API currently
doesn't enable clocks for netcp due to a limitation. This workaround is
expected to be removed in the future when proper API support becomes
available. Until then, this work around is needed.
Document Author
---------------
Murali Karicheri <m-karicheri2@ti.com>
Documentation/arm/keystone/knav-qmss.txt
+56
View File
@@ -0,0 +1,56 @@
* Texas Instruments Keystone Navigator Queue Management SubSystem driver
Driver source code path
drivers/soc/ti/knav_qmss.c
drivers/soc/ti/knav_qmss_acc.c
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
DT documentation is available at
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
Accumulator QMSS queues using PDSP firmware
============================================
The QMSS PDSP firmware support accumulator channel that can monitor a single
queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
driver that interface with the accumulator PDSP. This configures
accumulator channels defined in DTS (example in DT documentation) to monitor
1 or 32 queues per channel. More description on the firmware is available in
CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
git://git.ti.com/keystone-rtos/qmss-lld.git
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
To use copy the firmware image to lib/firmware folder of the initramfs or
ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
Use of accumulated queues requires the firmware image to be present in the
file system. The driver doesn't acc queues to the supported queue range if
PDSP is not running in the SoC. The API call fails if there is a queue open
request to an acc queue and PDSP is not running. So make sure to copy firmware
to file system before using these queue types.
Documentation/arm/sunxi/README
+1 -1
View File
@@ -25,7 +25,7 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Allwinner A13 (sun5i)
- Allwinner A13 / R8 (sun5i)
+ Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ User Manual
Documentation/block/null_blk.txt
+3
View File
@@ -70,3 +70,6 @@ use_per_node_hctx=[0/1]: Default: 0
parameter.
1: The multi-queue block layer is instantiated with a hardware dispatch
queue for each CPU node in the system.
use_lightnvm=[0/1]: Default: 0
Register device with LightNVM. Requires blk-mq to be used.
Documentation/devicetree/bindings/arm/amlogic.txt
+8 -2
View File
@@ -9,6 +9,12 @@ Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";
Boards with the Amlogic Meson8b SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8b";
Board compatible values:
- "geniatech,atv1200"
- "minix,neo-x8"
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "tronfy,mxq" (Meson8b)
- "hardkernel,odroid-c1" (Meson8b)
Documentation/devicetree/bindings/arm/apm/scu.txt
+17
View File
@@ -0,0 +1,17 @@
APM X-GENE SoC series SCU Registers
This system clock unit contain various register that control block resets,
clock enable/disables, clock divisors and other deepsleep registers.
Properties:
- compatible : should contain two values. First value must be:
- "apm,xgene-scu"
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
scu: system-clk-controller@17000000 {
compatible = "apm,xgene-scu","syscon";
reg = <0x0 0x17000000 0x0 0x400>;
};
Documentation/devicetree/bindings/arm/arm,scpi.txt
+188
View File
@@ -0,0 +1,188 @@
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be "arm,scpi"
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
found in ../../misc/sysram.txt
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor
ID) as used by the firmware. Refer to
platform documentation for your
implementation for the IDs to use. For Juno
R0 and Juno R1 refer to [3].
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
+160 -2
View File
@@ -20,6 +20,25 @@ system control is required:
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
hif-cpubiuctrl node
-------------------
SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
(BIU) block which controls and interfaces the CPU complex to the different
Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
offers a feature called Write Pairing which consists in collapsing two adjacent
cache lines into a single (bursted) write transaction towards the memory
controller (MEMC) to maximize write bandwidth.
Required properties:
- compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
Optional properties:
- brcm,write-pairing:
Boolean property, which when present indicates that the chip
supports write-pairing.
example:
rdb {
#address-cells = <1>;
@@ -35,6 +54,7 @@ example:
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
hif_continuation: syscon@452000 {
@@ -43,8 +63,7 @@ example:
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
Nodes that allow for support of SMP initialization and reboot are required:
smpboot
-------
@@ -95,3 +114,142 @@ example:
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};
Power management
----------------
For power management (particularly, S2/S3/S5 system suspend), the following SoC
components are needed:
= Always-On control block (AON CTRL)
This hardware provides control registers for the "always-on" (even in low-power
modes) hardware, such as the Power Management State Machine (PMSM).
Required properties:
- compatible : should contain "brcm,brcmstb-aon-ctrl"
- reg : the register start and length for the AON CTRL block
Example:
aon-ctrl@410000 {
compatible = "brcm,brcmstb-aon-ctrl";
reg = <0x410000 0x400>;
};
= Memory controllers
A Broadcom STB SoC typically has a number of independent memory controllers,
each of which may have several associated hardware blocks, which are versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
associated with a number of hardware register resources (e.g., its PHY). See
the example device tree snippet below.
== MEMC (MEMory Controller)
Represents a single memory controller instance.
Required properties:
- compatible : should contain "brcm,brcmstb-memc" and "simple-bus"
Should contain subnodes for any of the following relevant hardware resources:
== DDR PHY control
Control registers for this memory controller's DDR PHY.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-ddr-phy-v225.1"
"brcm,brcmstb-ddr-phy-v240.1"
"brcm,brcmstb-ddr-phy-v240.2"
- reg : the DDR PHY register range
== DDR SHIMPHY
Control registers for this memory controller's DDR SHIMPHY.
Required properties:
- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0"
- reg : the DDR SHIMPHY register range
== MEMC DDR control
Sequencer DRAM parameters and control registers. Used for Self-Refresh
Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain "brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
Example:
memory_controllers {
ranges;
compatible = "simple-bus";
memc@0 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1106000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1106000 0x21c>;
};
shimphy@f1108000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1108000 0xe4>;
};
memc-ddr@f1102000 {
reg = <0xf1102000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@1 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1186000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1186000 0x21c>;
};
shimphy@f1188000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1188000 0xe4>;
};
memc-ddr@f1182000 {
reg = <0xf1182000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@2 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1206000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1206000 0x21c>;
};
shimphy@f1208000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1208000 0xe4>;
};
memc-ddr@f1202000 {
reg = <0xf1202000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
};
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
+34
View File
@@ -0,0 +1,34 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";
Documentation/devicetree/bindings/arm/coherency-fabric.txt
+5
View File
@@ -27,6 +27,11 @@ Required properties:
* For "marvell,armada-380-coherency-fabric", only one pair is needed
for the per-CPU fabric registers.
Optional properties:
- broken-idle: boolean to set when the Idle mode is not supported by the
hardware.
Examples:
coherency-fabric@d0020200 {
Documentation/devicetree/bindings/arm/cpus.txt
+2
View File
@@ -195,6 +195,8 @@ nodes to be present and contain the properties described below.
"marvell,armada-380-smp"
"marvell,armada-390-smp"
"marvell,armada-xp-smp"
"mediatek,mt6589-smp"
"mediatek,mt81xx-tz-smp"
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
Documentation/devicetree/bindings/arm/fsl.txt
+12 -4
View File
@@ -128,10 +128,18 @@ Example:
reg = <0x0 0x1ee0000 0x0 0x10000>;
};
Freescale LS2085A SoC Device Tree Bindings
------------------------------------------
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
----------------------------------------------------------------
LS2085A ARMv8 based Simulator model
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2085a-simu", "fsl,ls2085a";
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
LS2080A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
LS2080A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";

Some files were not shown because too many files have changed in this diff Show More