123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136 |
- Texas Instruments sysc 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). The sysc
- is mostly used for interaction between module and PRCM. It participates
- in the OCP Disconnect Protocol but other than that is mostly independent
- of the interconnect.
- Each interconnect target module can have one or more devices connected to
- it. There is a set of control registers for managing interconnect target
- module clocks, idle modes and interconnect level resets for the module.
- These control registers are sprinkled into the unused register address
- space of the first child device IP block managed by the interconnect
- target module and typically are named REVISION, SYSCONFIG and SYSSTATUS.
- Required standard properties:
- - compatible shall be one of the following generic types:
- "ti,sysc"
- "ti,sysc-omap2"
- "ti,sysc-omap4"
- "ti,sysc-omap4-simple"
- or one of the following derivative types for hardware
- needing special workarounds:
- "ti,sysc-omap2-timer"
- "ti,sysc-omap4-timer"
- "ti,sysc-omap3430-sr"
- "ti,sysc-omap3630-sr"
- "ti,sysc-omap4-sr"
- "ti,sysc-omap3-sham"
- "ti,sysc-omap-aes"
- "ti,sysc-mcasp"
- "ti,sysc-dra7-mcasp"
- "ti,sysc-usb-host-fs"
- "ti,sysc-dra7-mcan"
- - reg shall have register areas implemented for the interconnect
- target module in question such as revision, sysc and syss
- - reg-names shall contain the register names implemented for the
- interconnect target module in question such as
- "rev, "sysc", and "syss"
- - ranges shall contain the interconnect target module IO range
- 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
- Optional properties:
- - ti,sysc-mask shall contain mask of supported register bits for the
- SYSCONFIG register as documented in the Technical Reference
- Manual (TRM) for the interconnect target module
- - ti,sysc-midle list of master idle modes supported by the interconnect
- target module as documented in the TRM for SYSCONFIG
- register MIDLEMODE bits
- - ti,sysc-sidle list of slave idle modes supported by the interconnect
- target module as documented in the TRM for SYSCONFIG
- register SIDLEMODE bits
- - ti,sysc-delay-us delay needed after OCP softreset before accssing
- SYSCONFIG register again
- - ti,syss-mask optional mask of reset done status bits as described in the
- TRM for SYSSTATUS registers, typically 1 with some devices
- having separate reset done bits for children like OHCI and
- EHCI
- - clocks clock specifier for each name in the clock-names as
- specified in the binding documentation for ti-clkctrl,
- typically available for all interconnect targets on TI SoCs
- based on omap4 except if it's read-only register in hwauto
- mode as for example omap4 L4_CFG_CLKCTRL
- - clock-names should contain at least "fck", and optionally also "ick"
- depending on the SoC and the interconnect target module,
- some interconnect target modules also need additional
- optional clocks that can be specified as listed in TRM
- for the related CLKCTRL register bits 8 to 15 such as
- "dbclk" or "clk32k" depending on their role
- - ti,hwmods optional TI interconnect module name to use legacy
- hwmod platform data
- - ti,no-reset-on-init interconnect target module should not be reset at init
- - ti,no-idle-on-init interconnect target module should not be idled at init
- Example: Single instance of MUSB controller on omap4 using interconnect ranges
- using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000):
- target-module@2b000 { /* 0x4a0ab000, ap 84 12.0 */
- compatible = "ti,sysc-omap2";
- ti,hwmods = "usb_otg_hs";
- reg = <0x2b400 0x4>,
- <0x2b404 0x4>,
- <0x2b408 0x4>;
- reg-names = "rev", "sysc", "syss";
- clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
- clock-names = "fck";
- ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
- SYSC_OMAP2_SOFTRESET |
- SYSC_OMAP2_AUTOIDLE)>;
- ti,sysc-midle = <SYSC_IDLE_FORCE>,
- <SYSC_IDLE_NO>,
- <SYSC_IDLE_SMART>;
- ti,sysc-sidle = <SYSC_IDLE_FORCE>,
- <SYSC_IDLE_NO>,
- <SYSC_IDLE_SMART>,
- <SYSC_IDLE_SMART_WKUP>;
- ti,syss-mask = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x2b000 0x1000>;
- usb_otg_hs: otg@0 {
- compatible = "ti,omap4-musb";
- reg = <0x0 0x7ff>;
- interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
- usb-phy = <&usb2_phy>;
- ...
- };
- };
- 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 as children of a single interconnet target module.
|