snd_hdspe(4): One pcm device per physical ADAT port.

[dev_submerge.ch]

Summary

ADAT connections transport 8, 4, or 2 audio channels depending on the
sample rate. Instead of splitting each physical ADAT port into 4
(potentially unmapped) stereo pcm devices, create just one pcm
device of variable channel width for every ADAT port.
Depending on the sample rate and channel width selected, the pcm
channels may be only partially mapped to ADAT channels and vice versa.

Added flexibility of the new channel mapping is also prerequisite to
introduce more pcm device layouts in follow-up commits.

[dev_submerge.ch]

Tested on 15.0-CURRENT as of 2024-01-09, on amd64 with an RME HDSPe RayDAT card. I have this code in use for several months now, as a separate kernel module from ports.

@br: This patch includes the restructured pcm layout and the basic functionality needed for composed pcm devices. The alternative layout that combines all physical ports into one pcm device will be subject to a follow-up patch. I also left out the sysctl settings for sample rate and block size (period).

Since these changes are prerequisite for composed pcm devices, some of the code may be more generic than necessary at this point, e.g. handle multiple physical ports at once. This is also the reason to represent physical ports as bitsets.

Due to ADAT channel width depending on sample rate, DMA slot offset and widths of physical ports change at runtime. These are now encoded in functions instead of table entries.

Variable pcm channel width depending on sample rate cannot be reliably handled by OSS API / pcm device configuration. Therefore we have to support every possible channel width / sample rate combination, see capabilities' format list.

[dev_submerge.ch]

Regarding future support of additional RME cards, I looked briefly into that when I decided for the bitset approach on physical ports. Obviously there's a limit to that (32 bits). But physical ports on the AIO Pro look like the same as AIO, MADI FX has 5 ports and the others have even less. Thus I wouldn't worry too much about this limit, we may have to adapt more aspects of the driver anyway. The linux driver for example handles MADI and AES in separate files from AIO and RayDAT.

[br]

looks very good

sys/dev/sound/pci/hdspe-pcm.c

101

return statements should be enclosed in parentheses

107

can we use ffs(3)?

549–550

we can remove braces as other parts of driver do not use it

[dev_submerge.ch]

Thanks. I'll fix the style(9) issues you mentioned and some more that I just spotted now - probably tomorrow.

sys/dev/sound/pci/hdspe-pcm.c

107

ffs(3) is sort of a detour here, as it returns the index of the first bit, not the value. We'd have to check for zero first and then return (1 << (index - 1)). I know the bit operations here and in hdspe_port_first_row() may be non-obvious to the casual reader, but I hope the comments give enough context?

[dev_submerge.ch]

Fixed various style(9) issues.