Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Olof Johansson: "Driver updates for ARM SoCs. Some for SoC-family code under drivers/soc, but also some other driver updates that don't belong anywhere else. We also bring in the drivers/reset code through arm-soc. Some of the larger updates: - Qualcomm support for SMEM, SMSM, SMP2P. All used to communicate with other parts of the chip/board on these platforms, all proprietary protocols that don't fit into other subsystems and live in drivers/soc for now. - System bus driver for UniPhier - Driver for the TI Wakeup M3 IPC device - Power management for Raspberry PI + Again a bunch of other smaller updates and patches" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (38 commits) bus: uniphier: allow only built-in driver ARM: bcm2835: clarify RASPBERRYPI_FIRMWARE dependency MAINTAINERS: Drop Kumar Gala from QCOM bus: uniphier-system-bus: add UniPhier System Bus driver ARM: bcm2835: add rpi power domain driver dt-bindings: add rpi power domain driver bindings ARM: bcm2835: Define two new packets from the latest firmware. drivers/soc: make mediatek/mtk-scpsys.c explicitly non-modular soc: mediatek: SCPSYS: Add regulator support MAINTAINERS: Change QCOM entries soc: qcom: smd-rpm: Add existing platform support memory/tegra: Add number of TLB lines for Tegra124 reset: hi6220: fix modular build soc: qcom: Introduce WCNSS_CTRL SMD client ARM: qcom: select ARM_CPU_SUSPEND for power management MAINTAINERS: Add rules for Qualcomm dts files soc: qcom: enable smsm/smp2p modular build serial: msm_serial: Make config tristate soc: qcom: smp2p: Qualcomm Shared Memory Point to Point soc: qcom: smsm: Add driver for Qualcomm SMSM ...
This commit is contained in:
@@ -0,0 +1,66 @@
|
||||
UniPhier System Bus
|
||||
|
||||
The UniPhier System Bus is an external bus that connects on-board devices to
|
||||
the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
|
||||
some control signals. It supports up to 8 banks (chip selects).
|
||||
|
||||
Before any access to the bus, the bus controller must be configured; the bus
|
||||
controller registers provide the control for the translation from the offset
|
||||
within each bank to the CPU-viewed address. The needed setup includes the base
|
||||
address, the size of each bank. Optionally, some timing parameters can be
|
||||
optimized for faster bus access.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "socionext,uniphier-system-bus".
|
||||
- reg: offset and length of the register set for the bus controller device.
|
||||
- #address-cells: should be 2. The first cell is the bank number (chip select).
|
||||
The second cell is the address offset within the bank.
|
||||
- #size-cells: should be 1.
|
||||
- ranges: should provide a proper address translation from the System Bus to
|
||||
the parent bus.
|
||||
|
||||
Note:
|
||||
The address region(s) that can be assigned for the System Bus is implementation
|
||||
defined. Some SoCs can use 0x00000000-0x0fffffff and 0x40000000-0x4fffffff,
|
||||
while other SoCs can only use 0x40000000-0x4fffffff. There might be additional
|
||||
limitations depending on SoCs and the boot mode. The address translation is
|
||||
arbitrary as long as the banks are assigned in the supported address space with
|
||||
the required alignment and they do not overlap one another.
|
||||
For example, it is possible to map:
|
||||
bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff
|
||||
It is also possible to map:
|
||||
bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff
|
||||
There is no reason to stick to a particular translation mapping, but the
|
||||
"ranges" property should provide a "reasonable" default that is known to work.
|
||||
The software should initialize the bus controller according to it.
|
||||
|
||||
Example:
|
||||
|
||||
system-bus {
|
||||
compatible = "socionext,uniphier-system-bus";
|
||||
reg = <0x58c00000 0x400>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
ranges = <1 0x00000000 0x42000000 0x02000000
|
||||
5 0x00000000 0x46000000 0x01000000>;
|
||||
|
||||
ethernet@1,01f00000 {
|
||||
compatible = "smsc,lan9115";
|
||||
reg = <1 0x01f00000 0x1000>;
|
||||
interrupts = <0 48 4>
|
||||
phy-mode = "mii";
|
||||
};
|
||||
|
||||
uart@5,00200000 {
|
||||
compatible = "ns16550a";
|
||||
reg = <5 0x00200000 0x20>;
|
||||
interrupts = <0 49 4>
|
||||
clock-frequency = <12288000>;
|
||||
};
|
||||
};
|
||||
|
||||
In this example,
|
||||
- the Ethernet device is connected at the offset 0x01f00000 of CS1 and
|
||||
mapped to 0x43f00000 of the parent bus.
|
||||
- the UART device is connected at the offset 0x00200000 of CS5 and
|
||||
mapped to 0x46200000 of the parent bus.
|
@@ -0,0 +1,34 @@
|
||||
Hisilicon System Reset Controller
|
||||
======================================
|
||||
|
||||
Please also refer to reset.txt in this directory for common reset
|
||||
controller binding usage.
|
||||
|
||||
The reset controller registers are part of the system-ctl block on
|
||||
hi6220 SoC.
|
||||
|
||||
Required properties:
|
||||
- compatible: may be "hisilicon,hi6220-sysctrl"
|
||||
- reg: should be register base and length as documented in the
|
||||
datasheet
|
||||
- #reset-cells: 1, see below
|
||||
|
||||
Example:
|
||||
sys_ctrl: sys_ctrl@f7030000 {
|
||||
compatible = "hisilicon,hi6220-sysctrl", "syscon";
|
||||
reg = <0x0 0xf7030000 0x0 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Specifying reset lines connected to IP modules
|
||||
==============================================
|
||||
example:
|
||||
|
||||
uart1: serial@..... {
|
||||
...
|
||||
resets = <&sys_ctrl PERIPH_RSTEN3_UART1>;
|
||||
...
|
||||
};
|
||||
|
||||
The index could be found in <dt-bindings/reset/hisi,hi6220-resets.h>.
|
@@ -0,0 +1,47 @@
|
||||
Raspberry Pi power domain driver
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "raspberrypi,bcm2835-power".
|
||||
- firmware: Reference to the RPi firmware device node.
|
||||
- #power-domain-cells: Should be <1>, we providing multiple power domains.
|
||||
|
||||
The valid defines for power domain are:
|
||||
|
||||
RPI_POWER_DOMAIN_I2C0
|
||||
RPI_POWER_DOMAIN_I2C1
|
||||
RPI_POWER_DOMAIN_I2C2
|
||||
RPI_POWER_DOMAIN_VIDEO_SCALER
|
||||
RPI_POWER_DOMAIN_VPU1
|
||||
RPI_POWER_DOMAIN_HDMI
|
||||
RPI_POWER_DOMAIN_USB
|
||||
RPI_POWER_DOMAIN_VEC
|
||||
RPI_POWER_DOMAIN_JPEG
|
||||
RPI_POWER_DOMAIN_H264
|
||||
RPI_POWER_DOMAIN_V3D
|
||||
RPI_POWER_DOMAIN_ISP
|
||||
RPI_POWER_DOMAIN_UNICAM0
|
||||
RPI_POWER_DOMAIN_UNICAM1
|
||||
RPI_POWER_DOMAIN_CCP2RX
|
||||
RPI_POWER_DOMAIN_CSI2
|
||||
RPI_POWER_DOMAIN_CPI
|
||||
RPI_POWER_DOMAIN_DSI0
|
||||
RPI_POWER_DOMAIN_DSI1
|
||||
RPI_POWER_DOMAIN_TRANSPOSER
|
||||
RPI_POWER_DOMAIN_CCP2TX
|
||||
RPI_POWER_DOMAIN_CDP
|
||||
RPI_POWER_DOMAIN_ARM
|
||||
|
||||
Example:
|
||||
|
||||
power: power {
|
||||
compatible = "raspberrypi,bcm2835-power";
|
||||
firmware = <&firmware>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
Example for using power domain:
|
||||
|
||||
&usb {
|
||||
power-domains = <&power RPI_POWER_DOMAIN_USB>;
|
||||
};
|
57
Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
Normal file
57
Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
Normal file
@@ -0,0 +1,57 @@
|
||||
Wakeup M3 IPC Driver
|
||||
=====================
|
||||
|
||||
The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
|
||||
(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks
|
||||
that cannot be controlled from the MPU, like suspend/resume and certain deep
|
||||
C-states for CPU Idle. Once the wkup_m3_ipc driver uses the wkup_m3_rproc driver
|
||||
to boot the wkup_m3, it handles communication with the CM3 using IPC registers
|
||||
present in the SoC's control module and a mailbox. The wkup_m3_ipc exposes an
|
||||
API to allow the SoC PM code to execute specific PM tasks.
|
||||
|
||||
Wkup M3 Device Node:
|
||||
====================
|
||||
A wkup_m3_ipc device node is used to represent the IPC registers within an
|
||||
SoC.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
- compatible: Should be,
|
||||
"ti,am3352-wkup-m3-ipc" for AM33xx SoCs
|
||||
"ti,am4372-wkup-m3-ipc" for AM43xx SoCs
|
||||
- reg: Contains the IPC register address space to communicate
|
||||
with the Wakeup M3 processor
|
||||
- interrupts: Contains the interrupt information for the wkup_m3
|
||||
interrupt that signals the MPU.
|
||||
- ti,rproc: phandle to the wkup_m3 rproc node so the IPC driver
|
||||
can boot it.
|
||||
- mboxes: phandles used by IPC framework to get correct mbox
|
||||
channel for communication. Must point to appropriate
|
||||
mbox_wkupm3 child node.
|
||||
|
||||
Example:
|
||||
--------
|
||||
/* AM33xx */
|
||||
l4_wkup: l4_wkup@44c00000 {
|
||||
...
|
||||
|
||||
scm: scm@210000 {
|
||||
compatible = "ti,am3-scm", "simple-bus";
|
||||
reg = <0x210000 0x2000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x210000 0x2000>;
|
||||
|
||||
...
|
||||
|
||||
wkup_m3_ipc: wkup_m3_ipc@1324 {
|
||||
compatible = "ti,am3352-wkup-m3-ipc";
|
||||
reg = <0x1324 0x24>;
|
||||
interrupts = <78>;
|
||||
ti,rproc = <&wkup_m3>;
|
||||
mboxes = <&mailbox &mbox_wkupm3>;
|
||||
};
|
||||
|
||||
...
|
||||
};
|
||||
};
|
Reference in New Issue
Block a user