#
4cd96614 |
| 07-Apr-2023 |
Dmitry Salychev <dsl@FreeBSD.org> |
dpaa2: Avoid dpaa2_cmd race conditions
struct dpaa2_cmd is no longer malloc'ed, but can be allocated on stack and initialized with DPAA2_CMD_INIT() on demand. Drivers stopped caching their DPAA2 com
dpaa2: Avoid dpaa2_cmd race conditions
struct dpaa2_cmd is no longer malloc'ed, but can be allocated on stack and initialized with DPAA2_CMD_INIT() on demand. Drivers stopped caching their DPAA2 command objects (and associated tokens) in the software contexts in order to avoid using them concurrently.
Reviewed by: bz Approved by: bz (mentor) MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D39509
show more ...
|
#
ba7319e9 |
| 20-Sep-2022 |
Dmitry Salychev <dsl@FreeBSD.org> |
Add initial DPAA2 support
DPAA2 is a hardware-level networking architecture found in some NXP SoCs which contain hardware blocks including Management Complex (MC, a command interface to manipulate D
Add initial DPAA2 support
DPAA2 is a hardware-level networking architecture found in some NXP SoCs which contain hardware blocks including Management Complex (MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O processor (WRIOP, packets distribution, queuing, drop decisions), Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2 objects as an abstraction layer over those blocks to simplify an access to the underlying hardware. Each DPAA2 object has its own driver (to perform an initialization at least) and will be visible as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX) dpaa2_mcX dpaa2_rcX dpaa2_mcp0 ... dpaa2_mcpN dpaa2_bpX dpaa2_macX dpaa2_io0 ... dpaa2_ioM dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI and FDT flavours and implements helper interfaces to allocate and assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some of the objects as resources for the other DPAA2 objects to let them function properly). Almost all of the DPAA2 objects are assigned to the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface to be operational. It is the most complex object in terms of dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor) Tested by: manu, bz MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D36638
show more ...
|