hc
2023-10-25 6c2073b7aa40e29d0eca7d571dd7bc590c7ecaa7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
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.