With the recently introduced omap clkctrl module binding, we can start
moving omap hwmod data to device tree and drivers from arch/arm/mach-omap2.
To start doing this, let's introduce a device tree binding for TI
interconnect target module hardware that manages the individual device IP
blocks on various interconnects for TI SoCs. The resources managed for the
child IP blocks are clocks, idlemodes and interconnect level resets.
TI interconnect target module hardware is the same for modules, and is
independent of the interconnect. It is used at least with TI L3
interconnect (Arteris NoC) and TI L4 interconnect (Sonics s3220).
As all the features may not be supported for a given module, we need to
use device tree configuration for the revision of the interconnect target
module and things like supported master and slave idle modes.
Note that the interconnect target module control registers for the whole
module (including it's children) are always sprinked into the unused
address space of the first device IP block that the interconnect target
module manages.
To avoid IO range conflicts, we can have the interconnect target module
probe it's children and provide IO ranges for the children along with
other services such as implementing runtime PM for the shared module
clock.
The reason for doing this is to simplify adding support for new devices.
Currently we need to modify clock aliases, static hwmod data, device tree
data and the driver even for simple devices.
With the recently introduced clkctrl binding the need to modify clock
aliases will go away. And when the interconnect target module can be
configured using device tree, the need to modify static hwmod data goes
away. So eventually we only need to modify the device tree and the
driver.
Also further changes for power management will be easier as the
interconnect, power domain, and clock domain hierarcy can be made
available in a standard way for Linux PM domains support via device
tree.
For a non-intrusive transition from static hwmod data to using device
tree defined TI interconnect target module binding, we can keep things
working the existing way if device tree property "ti,hwmods" is
specified in the dtb.
Cc: Benoît Cousson <bcousson@xxxxxxxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Cc: Nishanth Menon <nm@xxxxxx>
Cc: Matthijs van Duin <matthijsvanduin@xxxxxxxxx>
Cc: Paul Walmsley <paul@xxxxxxxxx>
Cc: Peter Ujfalusi <peter.ujfalusi@xxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: Tero Kristo <t-kristo@xxxxxx>
Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
---
.../devicetree/bindings/bus/ti-ipwrap.txt | 153 +++++++++++++++++++++
1 file changed, 153 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti-ipwrap.txt
diff --git a/Documentation/devicetree/bindings/bus/ti-ipwrap.txt b/Documentation/devicetree/bindings/bus/ti-ipwrap.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-ipwrap.txt
@@ -0,0 +1,153 @@
+Texas Instruments interconnect target module wrapper binding
+
+Texas Instruments SoCs can have a generic interconnect target module
+hardware for devices connected to various interconnects such as L3
+interconnect (Arteris NoC) and L4 interconnect (Sonics s3220).
+
+Each interconnect target module can have one or more devices connected to
+it. Each interconnect target module has a single set of registers for
+managing clocks, idle modes and interconnect level resets for the module
+including all the child devices connected to it.
+
+The interconnect target module registers are sprinkled into the unused
+register address space of the first device IP block managed by the
+interconnect target module.
+
+As an interconnect target module can manage more than one child device,
+the interconnect target module probes the child devices and implements
+runtime PM for them. The child device drivers can access individual
+device registers using register ranges provided by the interconnect
+target module.
+
+Required standard properties:
+
+- compatible shall be one of the following generic types:
+
+ "ti,sysc-type1"
+ "ti,sysc-type2"
+ "ti,sysc-type3"
+
+ or one of the following derivative types for hardware
+ needing special workarounds:
+
+ "ti,sysc-omap3430-sr"
+ "ti,sysc-omap3630-sr"
+ "ti,sysc-omap3-sham"
+ "ti,sysc-omap-aes"
+ "ti,sysc-mcasp"
+ "ti,sysc-smartreflex"
+ "ti,sysc-usb-host-fs"
+
+- reg shall have register areas for the registers implemented
+ for the interconnect target module in question such as
+ revision, sysc and syss and ip0
+
+- reg-names shall contain the register names implemented for the
+ interconnect target module in question such as
+ "rev, "sysc", "syss" and "ip0"
+
+- ranges shall contain the register ranges available for one or more
+ child device IP blocks managed by the interconnect target
+ module, the ranges may include multiple ranges such as
+ device L4 range for control and parent L3 range for DMA
+ access
+
+- clocks shall contain the clocks managed by the interconnect target
+ module, typically at least the clkctrl clock of the module
+
+- clock-names shall contain names of the clock managed by the interconnect
+ target module such as "clkctrl"
+
+Optional custom properties:
+
+- ti,sysc-has-clockactivity interconnect target module supports SYSCONFIG
+ register CLOCKACTIVITY feature, available for
+ "ti,sysc-type1" and "ti,sysc-type2"
+
+- ti,sysc-has-enawakeup interconnect target module supports SYSCONFIG
+ register ENAWAKEUP feature, available for
+ "ti,sysc-type1" and "ti,sysc-type2"
+
+- ti,sysc-has-softreset interconnect target module supports SYSCONFIG
+ register SOFTRESET feature, available for
+ "ti,sysc-type1" and "ti,sysc-type2"
+
+- ti,sysc-has-autoidle interconnect target module supports SYSCONFIG
+ register AUTOIDLE feature, available for
+ "ti,sysc-type1" and "ti,sysc-type2"
+
+- ti,sysc-has-dmadisable interconnect target module supports SYSCONFIG
+ DMADISABLE feature, only available for
+ "ti,sysc-type2"
+
+- ti,sysc-idlemodes-master list of master idle modes supported by the
+ interconnect target module as documented for
+ SYSCONFIG register MIDLEMODE bits, available on
+ "ti,sysc-type1", "ti,sysc-type2" and
+ "ti,sysc-type3"
+
+- ti,sysc-idlemodes-slave list of slave idle modes supported by the
+ interconnect target module as documented for
+ SYSCONFIG register SIDLEMODE bits, available on
+ "ti,sysc-type1", "ti,sysc-type2" and
+ "ti,sysc-type3"
+
+- ti,syss-has-reset-status interconnect target module supports SYSSTATUS
+ register RESETDONE feature
+
+- ti,quirk-swsup-slave-idle quirk to manually bring module out of idle,
+ rely on smart-idle to put it back to idle
+
+- ti,quirk-swsup-master-standby quirk to keep MIDLEMODE bits cleared so that
+ device is kept in force-standby mode
+
+Example: Single instance of MUSB controller on omap4 using interconnect ranges:
+
+ target_module@2b000 { /* 0x4a0ab000, ap 84 12.0 */
+ compatible = "ti,sysc-type1", "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x54 0x400 0x4
+ 0x54 0x404 0x4
+ 0x54 0x408 0x4
+ 0x54 0 0x001000>;
+ reg-names = "rev", "sysc", "syss", "ip0";
+ ranges = <0 0 0x54 0 0x001000>;
+ clocks = <&cm_l3init_clkctrl OMAP4_OTG_CLKCTRL 0>;
+ clock-names = "clkctrl";
+
+ ti,sysc-has-autoidle;
+ ti,sysc-has-enawakeup;
+ ti,sysc-has-softreset;
+ ti,sysc-idlemodes-master = <TI_SYSC_IDLE_FORCE
+ TI_SYSC_IDLE_NONE
+ TI_SYSC_IDLE_SMART>;
+ ti,sysc-idlemodes-slave = <TI_SYSC_IDLE_FORCE
+ TI_SYSC_IDLE_NONE
+ TI_SYSC_IDLE_SMART
+ TI_SYSC_IDLE_SMART_WKUP>;
+
+ ti,syss-has-reset-status;
+
+ ti,quirk-swsup-slave-idle;
+ ti,quirk-swsup-master-standby;
+
+ usb_otg_hs: usb_otg_hs@0 {
+ compatible = "ti,omap4-musb";
+ reg = <0 0 0x7ff>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIH>;
+ interrupt-names = "mc", "dma";
+ usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ ctrl-module = <&omap_control_usbotg>;
+ };
+ };
+
+Note that other SoCs, such as am335x can have multipe child devices. On am335x
+there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA
+instance in a single interconnet target module.
--
2.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
