arm/ti: attach EDMA3 against the split device tree binding

[rick_sloservers.com]

Summary

The ti_edma3 driver only attaches to device tree nodes with the
compatible string "ti,edma3". Current device trees no longer use it:
the binding was split into a channel controller ("ti,edma3-tpcc") and
separate transfer controllers ("ti,edma3-tptc"), so the driver never
attaches on am335x. Match the channel controller, and add a small
driver for the transfer controllers so their clocks get enabled, since
a gated transfer controller accepts requests but moves no data.

Also give the driver a per-instance softc and a kobj interface
(ti_edma3_if.m) for drivers that own a channel: allocate a channel,
load a chain of PaRAM sets, and start, check and stop a transfer.
Consumers find the controller through their "dmas" property.

Test Plan

Tested on a BeagleBone Black Rev B3 running stable/15 with the AM335x stack. The channel controller and all three transfer controllers attach, and with D59125 the SD controllers find their EDMA3 channels through "dmas" and DMA works.

Compile-checked against main with -Werror. Nothing in the tree builds these files without an AM335x kernel config, see D46703. There are boot logs and more details in PR 297800.

[oh]

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

[rick_sloservers.com]

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:

ti_sysc48: <dma@0> compat ti,edma3-tptc (no driver attached)
ti_sysc49: <dma@0> compat ti,edma3-tptc (no driver attached)
ti_sysc50: <dma@0> compat ti,edma3-tptc (no driver attached)

[mmel]

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?

Unfortunately, the entire TI code must be upgraded to the standard FreeBSD driver format — device/kobj methods instead of global functions, use DT for driver linkage, etc. Remember that global variables or functions in drivers are almost always an indication of wrong design.

[rick_sloservers.com]

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

But you're right that I was building on the wrong pattern, so I've reworked it: ti_edma3 now has a per-instance softc and a small kobj interface, it registers its xref, and ti_sdhci finds the controller and its channels through dmas. D59125 is updated to match.

Is this closer to what you had in mind?

[mmel]

Yes, this is definitely a step in the right direction.

The next step should be to split the code into common parts, since the 'DMA' properties and machinery are not TI-specific but are widely used on other platforms. The dev/regulator framework would be a good place to start (including regdev/node_if.h and the common functions in regulator.h).

Unfortunately, I am not very responsive at the moment and will not be for the next few weeks, as I am in hospital and only have internet access via mobile a few times per week. It is unlikely that this will change by the end of the month.