Skip to content

Commit 08a0df6

Browse files
author
Jacob Stiffler
committed
Merge pull request torvalds#189 in PROCESSOR-SDK/processor-sdk-linux from processor-sdk-linux-4.19.y_merge_ti2019.04 to processor-sdk-linux-4.19.y
* commit '36758aa6f88968622e04e397d810f2c037744db0': (1505 commits) arm64: dts: k3-j721e: Add gpio-keys on alpha proc board clk: ti: dra7-atl-clock: Remove unused variable arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu net: phy: dp83867: enable robust auto-mdix HACK: Revert "net: ethernet: ti: am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()" arm64: dts: ti: k3-j721e-mcu-wakeup: Increase HBMC bus clock to 125MHz mmc: sdhci_am654: Remove Inverted Write Protect flag arm64: dts: ti: k3-j721-common-proc-board: Fix write protect handling arm64: dts: ti: k3-am654-base-board: Fix MMC Write Protect handling arm64: dts: k3-j721e-proc-board-tps65917: change cpsw2g interface mode to rgmii-rxid arm64: dts: k3-j721e-common-proc-board: change cpsw2g interface mode to rgmii-rxid arm64: dts: ti: k3-j721e-proc-board-tps65917: disable main_uart2 for eth switch fw remoteproc/k3-dsp: fix memzero issues with C66x L2SRAM remoteproc/k3-r5: fix memzero issues on reserved SRAM regions remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses remoteproc/k3-r5: fix unaligned data faults with TCMs during loading crypto: Kconfig: sa2ul: select SHA512/SHA256 explicitly clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call dmaengine: ti: k3-navss-udma: Reset flowid range when no extra flows needed dmaengine: ti: k3-udma: Make sure that extra flows are disabled for rchan ...
2 parents 5f8c1c6 + 36758aa commit 08a0df6

File tree

1,421 files changed

+29885
-9119
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,421 files changed

+29885
-9119
lines changed

‎Documentation/ABI/testing/sysfs-class-remoteproc

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -48,3 +48,13 @@ Description: Remote processor state
4848

4949
Writing "stop" will attempt to halt the remote processor and
5050
return it to the "offline" state.
51+
52+
What: /sys/class/remoteproc/.../name
53+
Date: August 2019
54+
KernelVersion: 5.4
55+
Contact: Suman Anna <[email protected]>
56+
Description: Remote processor name
57+
58+
Reports the name of the remote processor. This can be used by
59+
userspace in exactly identifying a remote processor and ease
60+
up the usage in modifying the 'firmware' or 'state' files.

‎Documentation/PCI/endpoint/pci-test-ntb.txt

Lines changed: 315 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,315 @@
1+
PCI NTB FUNCTION
2+
Kishon Vijay Abraham I <[email protected]>
3+
4+
PCI NTB Function allows two different systems (or hosts) to communicate
5+
with each other by configurig the endpoint instances in such a way that
6+
transactions from one system is routed to the other system.
7+
8+
In the below diagram, PCI NTB function configures the SoC with multiple
9+
PCIe Endpoint (EP) instances in such a way that transaction from one EP
10+
controller is routed to the other EP controller. Once PCI NTB function
11+
configures the SoC with multiple EP instances, HOST1 and HOST2 can
12+
communicate with each other using SoC as a bridge.
13+
14+
+-------------+ +-------------+
15+
| | | |
16+
| HOST1 | | HOST2 |
17+
| | | |
18+
+------^------+ +------^------+
19+
| |
20+
| |
21+
+---------|-------------------------------------------------|---------+
22+
| +------v------+ +------v------+ |
23+
| | | | | |
24+
| | EP | | EP | |
25+
| | CONTROLLER1 | | CONTROLLER2 | |
26+
| | <-----------------------------------> | |
27+
| | | | | |
28+
| | | | | |
29+
| | | SoC With Multiple EP Instances | | |
30+
| | | (Configured using NTB Function) | | |
31+
| +-------------+ +-------------+ |
32+
+---------------------------------------------------------------------+
33+
34+
Constructs used for Implementing NTB:
35+
36+
*) Config Region
37+
*) Self Scratchpad Registers
38+
*) Peer Scratchpad Registers
39+
*) Doorbell Registers
40+
*) Memory Window
41+
42+
Modeling Constructs:
43+
44+
There are 5 or more distinct regions (config, self scratchpad, peer
45+
scratchpad, doorbell, one or more memory windows) to be modeled to achieve
46+
NTB functionality. Atleast one memory window is required while more than
47+
one is permitted. All these regions should be mapped to BAR for hosts to
48+
access these regions.
49+
50+
If one 32-bit BAR is allocated for each of these regions, the scheme would
51+
look like
52+
BAR0 -> Config Region
53+
BAR1 -> Self Scratchpad
54+
BAR2 -> Peer Scratchpad
55+
BAR3 -> Doorbell
56+
BAR4 -> Memory Window 1
57+
BAR5 -> Memory Window 2
58+
59+
However if we allocate a separate BAR for each of the region, there would not
60+
be enough BARs for all the regions in a platform that supports only 64-bit
61+
BAR.
62+
63+
In order to be be supported by most of the platforms, the regions should be
64+
packed and mapped to BARs in a way that provides NTB functionality and
65+
also making sure the hosts doesn't access any region that it is not supposed
66+
to.
67+
68+
The following scheme is used in EPF NTB Function
69+
70+
BAR0 -> Config Region + Self Scratchpad
71+
BAR1 -> Peer Scratchpad
72+
BAR2 -> Doorbell + Memory Window 1
73+
BAR3 -> Memory Window 2
74+
BAR4 -> Memory Window 3
75+
BAR4 -> Memory Window 4
76+
77+
With this scheme, for the basic NTB functionality 3 BARs should be sufficient.
78+
79+
Modeling Config/Scratchpad Region:
80+
81+
+-----------------+------->+------------------+ +-----------------+
82+
| BAR0 | | CONFIG REGION | | BAR0 |
83+
+-----------------+----+ +------------------+<-------+-----------------+
84+
| BAR1 | | |SCRATCHPAD REGION | | BAR1 |
85+
+-----------------+ +-->+------------------+<-------+-----------------+
86+
| BAR2 | Local Memory | BAR2 |
87+
+-----------------+ +-----------------+
88+
| BAR3 | | BAR3 |
89+
+-----------------+ +-----------------+
90+
| BAR4 | | BAR4 |
91+
+-----------------+ +-----------------+
92+
| BAR5 | | BAR5 |
93+
+-----------------+ +-----------------+
94+
EP CONTROLLER 1 EP CONTROLLER 2
95+
96+
Above diagram shows Config region + Scratchpad region for HOST1 (connected to
97+
EP controller 1) allocated in local memory. The HOST1 can access the config
98+
region and scratchpad region (self scratchpad) using BAR0 of EP controller 1.
99+
The peer host (HOST2 connected to EP controller 2) can also access this
100+
scratchpad region (peer scratchpad) using BAR1 of EP controller 2. This
101+
diagram shows the case where Config region and Scratchpad region is allocated
102+
for HOST1, however the same is applicable for HOST2.
103+
104+
Modeling Doorbell/Memory Window 1:
105+
106+
+-----------------+ +----->+----------------+-----------+-----------------+
107+
| BAR0 | | | Doorbell 1 +-----------> MSI|X ADDRESS 1 |
108+
+-----------------+ | +----------------+ +-----------------+
109+
| BAR1 | | | Doorbell 2 +---------+ | |
110+
+-----------------+ | +----------------+ | | |
111+
| BAR2 | | | Doorbell 3 +-------+ | +-----------------+
112+
+-----------------+ | +----------------+ | +-> MSI|X ADDRESS 2 |
113+
| BAR3 | | | Doorbell 4 +-----+ | +-----------------+
114+
+----------------------+ +----------------+ | | | |
115+
| BAR4 | | | | | +-----------------+
116+
+----------------------+ | MW1 +---+ | +-->+ MSI|X ADDRESS 3||
117+
| BAR5 | | | | | | +-----------------+
118+
+-----------------+ +----->-----------------+ | | | |
119+
EP CONTROLLER 1 | | | | +-----------------+
120+
| | | +---->+ MSI|X ADDRESS 4 |
121+
+----------------+ | +-----------------+
122+
EP CONTROLLER 2 | | |
123+
(OB SPACE) | | |
124+
+-------> MW1 |
125+
| |
126+
| |
127+
+-----------------+
128+
| |
129+
| |
130+
| |
131+
| |
132+
| |
133+
+-----------------+
134+
PCI Address Space
135+
(Managed by HOST2)
136+
137+
Above diagram shows how the doorbell and memory window 1 is mapped so that
138+
HOST1 can raise doorbell interrupt on HOST2 and also how HOST1 can access
139+
buffers exposed by HOST2 using memory window1 (MW1). Here doorbell and
140+
memory window 1 regions are allocated in EP controller 2 outbound (OB) address
141+
space. Allocating and configuring BARs for doorbell and memory window1
142+
is done during the initialization phase of NTB endpoint function driver.
143+
Mapping from EP controller 2 OB space to PCI address space is done when HOST2
144+
sends CMD_CONFIGURE_MW/CMD_CONFIGURE_DOORBELL. The commands are explained
145+
below.
146+
147+
Modeling Optional Memory Windows:
148+
149+
This is modeled the same was as MW1 but each of the additional memory windows
150+
is mapped to separate BARs.
151+
152+
Config Region:
153+
154+
Config Region is a construct that is specific to NTB implemented using NTB
155+
Endpoint Function Driver. The host and endpoint side NTB function driver will
156+
exchange informatio with each other using this region. Config Region has
157+
Control/Status Registers for configuring the Endpoint Controller. Host can
158+
write into this region for configuring the outbound ATU and to indicate the
159+
link status. Endpoint can indicate the status of commands issued be host in
160+
this region. Endpoint can also indicate the scratchpad offset, number of
161+
memory windows to the host using this region.
162+
163+
The format of Config Region is given below. Each of the fields here are 32
164+
bits.
165+
166+
+------------------------+
167+
| COMMAND |
168+
+------------------------+
169+
| ARGUMENT |
170+
+------------------------+
171+
| STATUS |
172+
+------------------------+
173+
| TOPOLOGY |
174+
+------------------------+
175+
| ADDRESS (LOWER 32) |
176+
+------------------------+
177+
| ADDRESS (UPPER 32) |
178+
+------------------------+
179+
| SIZE |
180+
+------------------------+
181+
| MEMORY WINDOW1 OFFSET |
182+
+------------------------+
183+
| NO OF MEMORY WINDOW |
184+
+------------------------+
185+
| SPAD OFFSET |
186+
+------------------------+
187+
| SPAD COUNT |
188+
+------------------------+
189+
| DB ENTRY SIZE |
190+
+------------------------+
191+
| DB DATA |
192+
+------------------------+
193+
| : |
194+
+------------------------+
195+
| : |
196+
+------------------------+
197+
| DB DATA |
198+
+------------------------+
199+
200+
201+
COMMAND:
202+
203+
NTB function supports three commands:
204+
205+
CMD_CONFIGURE_DOORBELL (0x1): Command to configure doorbell. Before
206+
invoking this command, the host should allocate and initialize
207+
MSI/MSI-X vectors (i.e initialize the MSI/MSI-X capability in the
208+
Endpoint). The endpoint on receiving this command will configure
209+
the outbound ATU such that transaction to DB BAR will be routed
210+
to the MSI/MSI-X address programmed by the host. The ARGUMENT
211+
register should be populated with number of DBs to configure (in the
212+
lower 16 bits) and if MSI or MSI-X should be configured (BIT 16).
213+
(TODO: Add support for MSI-X).
214+
215+
CMD_CONFIGURE_MW (0x2): Command to configure memory window. The
216+
host invokes this command after allocating a buffer that can be
217+
accessed by remote host. The allocated address should be programmed
218+
in the ADDRESS register (64 bit), the size should be programmed in
219+
the SIZE register and the memory window index should be programmed
220+
in the ARGUMENT register. The endpoint on receiving this command
221+
will configure the outbound ATU such that trasaction to MW BAR
222+
will be routed to the address provided by the host.
223+
224+
CMD_LINK_UP (0x3): Command to indicate an NTB application is
225+
bound to the EP device on the host side. Once the endpoint
226+
receives this command from both the hosts, the endpoint will
227+
raise an LINK_UP event to both the hosts to indicate the hosts
228+
can start communicating with each other.
229+
230+
ARGUMENT:
231+
232+
The value of this register is based on the commands issued in
233+
command register. See COMMAND section for more information.
234+
235+
configuring memory window and to indicate the host side NTB application
236+
has initialized.
237+
238+
TOPOLOGY:
239+
240+
Set to NTB_TOPO_B2B_USD for Primary interface
241+
Set to NTB_TOPO_B2B_DSD for Secondary interface
242+
243+
ADDRESS/SIZE:
244+
245+
Address and Size to be used while configuring the memory window.
246+
See "CMD_CONFIGURE_MW" for more info.
247+
248+
MEMORY WINDOW1 OFFSET:
249+
250+
Memory Window 1 and Doorbell registers are packed together in the
251+
same BAR. The initial portion of the region will have doorbell
252+
registers and the latter portion of the region is for memory window 1.
253+
This register will specify the offset of the memory window 1.
254+
255+
NO OF MEMORY WINDOW:
256+
257+
Specifies the number of memory windows supported by the NTB device.
258+
259+
SPAD OFFSET:
260+
261+
Self scratchpad region and config region are packed together in the
262+
same BAR. The initial portion of the will have config region and
263+
the latter portion of the region is for self scratchpad. This
264+
register will specify the offset of the self scratchpad registers.
265+
266+
SPAD COUNT:
267+
268+
Specifies the number of scratchpad registers supported by the NTB
269+
device.
270+
271+
DB ENTRY SIZE:
272+
273+
Used to determine the offset within the DB BAR that should be written
274+
in order to raise doorbell. EPF NTB can use either MSI/MSI-X to
275+
ring doorbell (MSI-X support will be added later). MSI uses same
276+
address for all the interrupts and MSI-X can provide different
277+
addresses for different interrupts. The MSI/MSI-X address is provided
278+
by the host and the address it gives is based on the MSI/MSI-X
279+
implementation supported by the host. For instance, ARM platform
280+
using GIC ITS will have same MSI-X address for all the interrupts.
281+
In order to support all the combinations and use the same mechanism
282+
for both MSI and MSI-X, EPF NTB allocates separate region in the
283+
Outbound Address Space for each of the interrupts. This region will
284+
be mapped to the MSI/MSI-X address provided by the host. If a host
285+
provides the same address for all the interrupts, all the regions
286+
will be translated to the same address. If a host provides different
287+
address, the regions will be translated to different address. This
288+
will ensure there is no difference while raising the doorbell.
289+
290+
DB DATA:
291+
292+
EPF NTB supports 32 interrupts. So there are 32 DB DATA registers.
293+
This holds the MSI/MSI-X data that has to be written to MSI address
294+
for raising doorbell interrupt. This will be populated by EPF NTB
295+
while invoking CMD_CONFIGURE_MW.
296+
297+
Scratchpad Registers:
298+
299+
Each host has it's own register space allocated in the memory of NTB EPC.
300+
They are both readable and writable from both sides of the bridge. They
301+
are used by applications built over NTB and can be used to pass control
302+
and status information between both sides of a device.
303+
304+
Scratchpad registers has 2 parts
305+
1) Self Scratchpad: Host's own register space
306+
2) Peer Scratchpad: Remote host's register space.
307+
308+
Doorbell Registers:
309+
310+
Registers using which one host can interrupt the other host.
311+
312+
Memory Window:
313+
314+
Actual transfer of data between the two hosts will happen using the
315+
memory window.

0 commit comments

Comments
 (0)