dpaa2: Clean up channels in separate tasksEach channel gets its own DMA resources, cleanup and "bufferpool"tasks, and a separate cleanup taskqueue to isolate channels operationas much as possible
dpaa2: Clean up channels in separate tasksEach channel gets its own DMA resources, cleanup and "bufferpool"tasks, and a separate cleanup taskqueue to isolate channels operationas much as possible to avoid various kernel panics under heavy networkload.As a side-effect of this work, dpaa2_buf structure is simplified andall of the functions to re-seed those buffers are gathered now indpaa2_buf.h and .c files; functions to work with channels areextracted into dpaa2_channel.h and .c files as well.Reported by: dchReviewed by: bzApproved by: bz (mentor)MFC after: 1 weekDifferential Revision: https://reviews.freebsd.org/D41296
show more ...
dpaa2: add console support for FDT based systemsAdd DPAA2 console support for MC and AIOP (latter untested) for FDTsystems. ACPI systems are prepared but need some proper bus functionin order to
dpaa2: add console support for FDT based systemsAdd DPAA2 console support for MC and AIOP (latter untested) for FDTsystems. ACPI systems are prepared but need some proper bus functionin order to get the address from MC (and likely a file splitup then).This will come at a later stage once other ACPI/FDT bus parts arecleared up.The work was originally done in July 2022 and finally switched tobus_space[1] lately to be ready for main.Suggested by: andrew [1]Reviewed by: dslMFC after: 2 weeksDifferential Revision: https://reviews.freebsd.org/D38592
sys/modules: fix bogus OPT_ACPI testsACPI is not handled specially by sys/conf/kern.opts.mk (unlike a fewoptions), so we should fall back on the generic behavior ofsys/conf/config.mk, which pulls
sys/modules: fix bogus OPT_ACPI testsACPI is not handled specially by sys/conf/kern.opts.mk (unlike a fewoptions), so we should fall back on the generic behavior ofsys/conf/config.mk, which pulls from all the generated opt*.h files,including opt_acpi.h, which will cause DEV_ACPI to be included inKERN_OPTS. Then the generic machinery in sys/conf/kmod.mk will causeSRCS.DEV_ACPI to be included in SRCS when appropriate.Reviewed by: jhb, impSponsored by: MicrosoftDifferential Revision: https://reviews.freebsd.org/D38737
dpaa2: cleanup some include files2782ed8f6cd3d7f59219a783bc7fa7bbfb1fe26f fixed the standalone modulebuild. REmove the now duplicate includes for opt_acpi.h andopt_platform.h. Als remove the if
dpaa2: cleanup some include files2782ed8f6cd3d7f59219a783bc7fa7bbfb1fe26f fixed the standalone modulebuild. REmove the now duplicate includes for opt_acpi.h andopt_platform.h. Als remove the if_mdio.h again in both the Makefileand the implementation file as it is not (currently) used.X-MFC with: ba7319e9091b4f6ef15a9c4be3d3d076f3047f72MFC after: 70 days
dpaa2: fix standalone module build
Add initial DPAA2 supportDPAA2 is a hardware-level networking architecture found in some NXPSoCs which contain hardware blocks including Management Complex(MC, a command interface to manipulate D
Add initial DPAA2 supportDPAA2 is a hardware-level networking architecture found in some NXPSoCs which contain hardware blocks including Management Complex(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/Oprocessor (WRIOP, packets distribution, queuing, drop decisions),Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx bufferpools) and the others.The Management Complex runs NXP-supplied firmware which provides DPAA2objects as an abstraction layer over those blocks to simplify anaccess to the underlying hardware. Each DPAA2 object has its owndriver (to perform an initialization at least) and will be visibleas a separate device in the device tree.Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses inorder 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_niXdpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPIand FDT flavours and implements helper interfaces to allocate andassign bus resources, MSI and "managed" DPAA2 devices (NXP treats someof the objects as resources for the other DPAA2 objects to let themfunction properly). Almost all of the DPAA2 objects are assigned tothe resource containers (dpaa2_rc) to implement isolation.The initial implementation focuses on the DPAA2 network interfaceto be operational. It is the most complex object in terms ofdependencies which uses I/O objects to transmit/receive packets.Approved by: bz (mentor)Tested by: manu, bzMFC after: 3 monthsDifferential Revision: https://reviews.freebsd.org/D36638