To answer your question, the ti_edma3tc instances never touched that global, it only ever held the one channel controller.

Updated to use the new ti_edma3 interface from D59124.

I'm sorry, but how does this work? There are multiple instances of 'ti_edma3tc' in the device tree (DT), so which one is stored in the single global softc?

This is a prerequisite for offloading the MMC data phase. On its own it attaches the engine and removes three unclaimed device tree nodes from the boot output:

This is pure hack, imho. The ACPI mux, buses and their devices must be enumerated in exactly the same way as in the FDT case.

@mmel and @wulf hey, this stack looks .. interesting to go and dig into as part of some other upcoming work. Would you mind taking a quick look at it and see what you think?
Thanks!

In D59264#1359759, @mmel wrote:

Another thing: Wouldn't it be much cleaner to extend the implementation of pmap_mapdev_attr() for early boot phase of armv7? subr_devmap.c looks ready for this job.

Thank you!
This landed as 533918ced28ccd3b6ce22c93e0b64deac40377a1. The revision was not automatically closed because the commit message is slightly different (uppercase "R" in remove).

This is a followup of 62d028dcac1a ("Switch BEAGLEBONE, CUBIEBOARD, and PANDABOARD to use the GENERIC kernel configuration.")
If there are no objections, I will commit this revision over the weekend.

Another thing: Wouldn't it be much cleaner to extend the implementation of pmap_mapdev_attr() for early boot phase of armv7? subr_devmap.c looks ready for this job.

I'm not thrilled with this solution.
The standard pre-pmap_bootstrap() KVA is 128 MB, including:

• kernel text/data/bss (section-mapped from KERNBASE);
• early page tables (kern_pt1, kern_pt2tab and initial L2 pages);
• whatever initarm() takes (dpcpu, stacks, msgbuf, etc.).

Looks good and works with PB&BB, maybe add in sys/arm/files.ti something like:
arm/ti/ti_edma3.c optional sdhci | edma3

Tested on hardware as part of this stack: D46703, D46712, D46713, D46714, D41888, D46722, D46723, D46742, D46743, D46744 and D46746 rebased from stable/14 onto stable/15 (6b25004d1d18), KERNCONF=AM335X, on a BeagleBone Black Rev B3. The board boots 15.1-STABLE to multi-user with zero device attach failures. Full results and evidence: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297800, discussion on D46723.

Applying the published diffs in dependency order onto current main
(ee81cd1d8f55):

address copyright/dates