summaryrefslogtreecommitdiff
path: root/drivers/iommu/apple_dart.c
AgeCommit message (Collapse)Author
2024-11-24iommu: apple: Mark device with DM_FLAG_VITALJanne Grunau
Avoids NULL pointer dereferences in apple_dart_unmap when the iommu device is removed before its user. U-boot's device model does not track dependencies between devices. Observed on a M1 Ultra Mac Studio with v2024.10. Acked-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Janne Grunau <j@jannau.net>
2024-11-11iommu: apple: Manage IOVA separately from global LMB mem mapJanne Grunau
There is no overlap between the IOVA space managed by the iommu (here the 32-bit address space) and physical RAM on Apple silicon systems. The RAM starts at 0x10_0000_0000 or 0x100_0000_0000 so it's not possible to manage the IOVA with the global memory LMB and use 1:1 translation. In addition each device has its own iommu and does not need to share the address space with all other devices. This should not be problem for u-boot's limited use and hardware support. Restore the private per instance LMB IOVA map. Fixes: ed17a33fed2 ("lmb: make LMB memory map persistent and global") Signed-off-by: Janne Grunau <j@jannau.net>
2024-09-03lmb: make LMB memory map persistent and globalSughosh Ganu
The current LMB API's for allocating and reserving memory use a per-caller based memory view. Memory allocated by a caller can then be overwritten by another caller. Make these allocations and reservations persistent using the alloced list data structure. Two alloced lists are declared -- one for the available(free) memory, and one for the used memory. Once full, the list can then be extended at runtime. [sjg: Use a stack to store pointer of lmb struct when running lmb tests] Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Signed-off-by: Simon Glass <sjg@chromium.org> [sjg: Optimise the logic to add a region in lmb_add_region_flags()]
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-07iommu: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-01-27iommu: apple: Implement DMA mapping operations for Apple DARTMark Kettenis
Implement translation table support for all the variations of Apple's DART IOMMU that can be found on Apple's M1 and M2 SoCs. Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
2022-07-25iommu: Add M2 support to Apple DART driverJanne Grunau
"apple,t8112-dart" uses an incompatible register interface but still offers the same functionality. This DART is found on the M2 and M1 Pro/Max/Ultra SoCs. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
2022-02-21iommu: Add M1 Pro/Max support to Apple DART driverJanne Grunau
For the purpose of this driver (activating bypass mode) t6000-dart and t8103-dart are fully compatible. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
2021-10-31iommu: Add Apple DART driverMark Kettenis
The DART is an IOMMU that is used on Apple's M1 SoC. This driver configures the DART such that it operates in bypass mode which is enough to support DMA for the USB3 ports integrated on the SoC. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Simon Glass <sjg@chromium.org>