Raspberry PI 4 S/PDIF audio mixer project (trying to get PCI sound card working)

[Darry]

Hi,

I thought I would share a personal project that came to be because I needed to mix multiple S/PDIF audio sources (so far 2 simultaneously out of 3 inputs, with an eventual aim of 4 inputs) whose clocks where not in sync . I currently use 4 USB sound cards (3 for input and 1 for output)

I hit some challenges along the way, the most significant of which was USB 1.1 bandwidth issues on the VL805 USB controller (I had to use the USB controller connected to the USB-C power port instead) and an unexplained issue with ALSA output at 24-bit/44.1KHz (all other bit depth and sample rate combinations worked) on multiple USB cards .

In the end (actually this is still ongoing), I got something that seems to work well for me .
The hardware I used is described here, without the exception of 4inch touchscreen, USB numeric keypad and cordless mouse, which were later additions : https://github.com/raspberrypi/linux/issues/3962 .
The software is essentially 32-bit Raspbian (current build as of writing this), jackd, jack_mixer and zita a2j bridge

The detailed journey and end result (so far) is chronicled here, including the very ugly script that starts everything at bootup : https://www.vogons.org/viewtopic.php?f=62&t=74902 .

I realize that this is just plugging together existing packages and connecting run of the mill consumer hardware, but it was a fun and productive journey for me after having looked for an affordable commercial solution (Roland M-1000 is certainly better and more flexible, but expensive and practically unobtainable) and having found no similar project that was within my skill-set .

Maybe this will help/inspire others to do something similar and hopefully better .

[Darry]

I have updated the Vogons thread with some RMAA loopback quality tests and some latency tests : https://www.vogons.org/viewtopic.php?p=947648#p947648

[cleverca22]

I hit some challenges along the way, the most significant of which was USB 1.1 bandwidth issues on the VL805 USB controller

i have heard that if you use a good quality usb3 hub, then you can fully max out every port on the hub at 2.0 or 1.0 speeds, while the hub itself is speaking 3.0 back to the host
dont know how well that would apply to the pi's specific usb controller, and possible cpu limitations on the arm side


another random thought, that may be of use, but you would maybe need to get an fpga into the mix, is smi:
https://iosoft.blog/2020/07/16/raspberry-pi-smi/

that can easily move 200mbit of data between an external chip and the gpio connector on the rpi
you would have to program the fpga to decode the spdif encoding, and then fire either spdif frames or raw pcm over the smi into the rpi
and smi is bi-directional, so you can also spit the data back out smi, and the fpga can re-create an spdif signal for output

[Darry]

I hit some challenges along the way, the most significant of which was USB 1.1 bandwidth issues on the VL805 USB controller

i have heard that if you use a good quality usb3 hub, then you can fully max out every port on the hub at 2.0 or 1.0 speeds, while the hub itself is speaking 3.0 back to the host
dont know how well that would apply to the pi's specific usb controller, and possible cpu limitations on the arm side


another random thought, that may be of use, but you would maybe need to get an fpga into the mix, is smi:
https://iosoft.blog/2020/07/16/raspberry-pi-smi/

that can easily move 200mbit of data between an external chip and the gpio connector on the rpi
you would have to program the fpga to decode the spdif encoding, and then fire either spdif frames or raw pcm over the smi into the rpi
and smi is bi-directional, so you can also spit the data back out smi, and the fpga can re-create an spdif signal for output

I did try connecting my USB 1.1devices through multi transaction translator USB 2.0 hub (encapsulates each USB 1.1 stream into a USB 2.0 one) on both the USB 2.0 and 3.0 ports provided by the integrated VL805 controller, but had no success (bandwidth issues) . AFAIK, there is no reason why this should not have just worked, unless there is a limitation/issue with the VL805 controller. Case in point, everything works fine with the same multi transaction translator USB 2.0 hub when connected to the Broadcom SOC's native USB 2.0 controller (albeit through an intermediate USB 3.0 hub that supports USB PD).

On the Via VL805 managed USB 2.0 and USB 3.0 ports, I can't even have a keyboard and mouse plugged it at the same time as Fiio E10K or only 2 Fiio E10Ks or only two CM106s without getting bandwidth errors. I don't think this is normal/expected behavior, please correct my if I am wrong . If there are USB 3.0 hubs that would compensate/correct that (and they are affordable/obtainable), I would be happy to try one, if somebody has any specific suggestions (USB 3.0 hub chipset and/or hub model). Additionally, if somebody has a potential explanation as to why my multi transaction translator USB 2.0 hub did not resolve the issue when connected to the VL805, I would be happy to know more about it .

Using an FPGA is beyond my current skillset and would probably add more to the BOM than I would be willing to spend at this point . Using I2S to S/PDIF interfaces instead of USB might be an option, if it is not too complex to implement and can be done more cheaply than the current USB method .

[cleverca22]

Using I2S to S/PDIF interfaces instead of USB might be an option, if it is not too complex to implement and can be done more cheaply than the current USB method .

but the i2s port is limited to stereo in and stereo out, so you cant capture very much

[Darry]

Using I2S to S/PDIF interfaces instead of USB might be an option, if it is not too complex to implement and can be done more cheaply than the current USB method .

but the i2s port is limited to stereo in and stereo out, so you cant capture very much

I was thinking about running multiple I2S over GPIO, if that is even possible (on a Pi or otherwise) .

[cleverca22]

Using I2S to S/PDIF interfaces instead of USB might be an option, if it is not too complex to implement and can be done more cheaply than the current USB method .

but the i2s port is limited to stereo in and stereo out, so you cant capture very much

I was thinking about running multiple I2S over GPIO, if that is even possible (on a Pi or otherwise) .

the properly hw accelerated i2s is limited to 2 in and 2 out channels

you could bit-bang more, but i dont know how easy it would be to meet the timing requirements of the protocol...

[Darry]

Having thought about it, bit banging I2S is probably beyond my abilities and this point and might not give better results than plain old USB devices anyway .

I did some more optimizing (including using a an RT kernel) and tests and have gotten round trip latency through the mixer down to about 12 milliseconds . Specific details are here : https://www.vogons.org/viewtopic.php?p=951015#p951015

Additionally, I will be trying different S/PDIF input hardware soon (my current choice has terribly build quality) .

[Darry]

Though I am still pursuing the idea of using USB S/PDIF input devices (UAC2 USB 2.0 high speed ones, which are incredibly hard to find at a low enough price), I have given up on USB 1.1 ones .One reason for this is that all UAC compliant USB 1.1 devices I have tried have a minimum period size of 45 (at 44.1KHz). Within that limitation, USB 1.1 devices, such as the CM106/CM6206 ones do work, but mine have marginal build quality . PCM2704 based USB 1.1 devices, such as the ADS Tech InstantMusic, also work but have the disadvantage of irrevocably auto-switching to their analogue input if no S/PDIF signal is detected (which adds noise at -75dB per such device).

Consequently, I have just ordered the following :

- a Pi 4 compute module
- a CMIO4 breakout board which has a PCI Express slot
- a PCI Express bridge board with 4 PCI Express slots
- 4 Creative SB1040 sound cards (based on the CA0110 chip). Spec sheet --> https://web.archive.org/web/20100215044 ... CA0110.pdf

I wonder if it this will actually work for my intended purpose .

On another note, if anyone is interested, I valiantly tried to use Pipewire, but never got good results out of it . See https://www.vogons.org/viewtopic.php?p=952708#p952708 and https://www.vogons.org/viewtopic.php?p=952835#p952835 I imagine that I should open a bug report, if what I am trying to do is supposed to work .

[6by9]

Though I am still pursuing the idea of using USB S/PDIF input devices (UAC2 USB 2.0 high speed ones, which are incredibly hard to find at a low enough price), I have given up on USB 1.1 ones .One reason for this is that all UAC compliant USB 1.1 devices I have tried have a minimum period size of 45 (at 44.1KHz). Within that limitation, USB 1.1 devices, such as the CM106/CM6206 ones do work, but mine have marginal build quality . PCM2704 based USB 1.1 devices, such as the ADS Tech InstantMusic, also work but have the disadvantage of irrevocably auto-switching to their analogue input if no S/PDIF signal is detected (which adds noise at -75dB per such device).

Consequently, I have just ordered the following :

- a Pi 4 compute module
- a CMIO4 breakout board which has a PCI Express slot
- a PCI Express bridge board with 4 PCI Express slots
- 4 Creative SB1040 sound cards (based on the CA0110 chip). Spec sheet --> https://web.archive.org/web/20100215044 ... CA0110.pdf

I wonder if it this will actually work for my intended purpose .

On another note, if anyone is interested, I valiantly tried to use Pipewire, but never got good results out of it . See https://www.vogons.org/viewtopic.php?p=952708#p952708 and https://www.vogons.org/viewtopic.php?p=952835#p952835 I imagine that I should open a bug report, if what I am trying to do is supposed to work .

Ordering 4 sound cards may have been a little premature, but there is a driver for them under CONFIG_SND_HDA_INTEL in the kernel. You'll need to build a custom kernel for your rig.
PCIe switches can be a little hit and miss - some devices work and others don't.

Jeff Geerling has been maintaining a set of PCIe cards that have been tested (by him or others). Sound cards don't appear to have been mentioned other than the request for someone to test them at https://github.com/geerlingguy/raspberr ... issues/100. It mainly seems to have been network (wired or wireless), SATA controllers and NVMe, some video cards (with limited success), and a few DVB tuners.

[Darry]

I admit that I was impulsive in my purchase of 4 sound cards that are completely untested on the Pi, but if they end up not being usable, I can always repurpose them in an x86 based project . As for PCIe switches, I had read of known issues as well and would be willing to shop around for a specific known working one if the one I ordered does not work (I can likely repurpose it in another project as well) . In the end, I won't be losing money over this (at least that's what I tell myself ).

I realize that I am going into uncharted territory with this, but whether it works as expected or not, trying it will have been time well spent . In all cases, I will recompile the Kernel with required options, test things out and report back for posterity .

Thank you for pointing out potential issues and mentioning Jeff Geerling's work .

[Darry]

Long story short : everything works, including the PCI Express bridge (ASM1184E), EXCEPT for the sound cards.
Typically, kernel module loads (or can be loaded manually using modprobe), but no ALSA device is available (nothing in /proc/asound/card* for the device). Using the aforementioned bridge (ASM1184E) and also a Startech PCI Express to PCI one , I tried (compiling and installing modules as needed):

SB1040 PCI Express (also tried this one directly in the PCI Express slot without using a bridge and got the same results)
SB0410 PCI
SB0610PCI
generic CM8738 based PCI card

Am I missing something really obvious ?

P.S. For the SB1040/CA0110 , I also tried compiling as kernel driver rather than a module and got the same results .

[6by9]

Plug one card directly into the PCIe slot on the CM4IO first as the PCIe switches can cause issues.
Check with "lspci -k" whether the kernel has found the relevant module as a driver for the card.
Check in dmesg for any errors on loading - that can be easiest if you add a blacklist for the module (via /etc/modprobe.d/) and then manually modprobe it.

I have seen some funnies with PCIe switches and interrupts not being routed, but I don't understand enough of it (or have enough time) to investigate at present. I have a quad DVB-T tuner that is actually 2 dual DVB-T tuners behind a switch, and that doesn't work for the same reason.

[Darry]

Hi 6by9,

I have the card plugged in directly (no bridge) and the driver is currently compiled into the kernel (not as a module, so I cannot load it manually. I did previously have it as a module and tried unloading/loading with no apparent errors) . dmesg is not showing any errors [1] . lspci -k shows [2] .

[1]
[Wed Apr 21 11:21:45 2021] snd_hda_intel 0000:02:00.0: enabling device (0000 -> 0002)
[Wed Apr 21 11:21:45 2021] snd_hda_intel 0000:02:00.0: Force to snoop mode by module option


[2]
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 PCI bridge: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG PCIe to PCI Bridge
02:00.0 Audio device: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio]
Subsystem: Creative Labs SB1040 PCI Express
Kernel driver in use: snd_hda_intel

[6by9]

Generally sticking with modules is easier - other than when Kconfig options are messed up, I've not seen a situation where switching between module and builtin has actually solved anything.

Your output looks promising, but you say "aplay -l" lists no devices. Weird.

Seeing as you've built your own custom kernel, throw some debug logging (a few extra dev_err lines) into azx_probe_continue in sound/pci/hda/hda_intel.c to see if it's stalling in there. There are no significant chances to abort in azx_create, but it schedules azx_probe_continue as a deferred worker thread.
There seems to be a lot of stuff in there which tries linking the audio device with a display device. I assuming that none of that is relevant for the CA0110-IBG, but it muddies the waters a bit.

[Darry]

I tried the trial firmware mentioned here viewtopic.php?p=1761834#p1761834 and downloadable here https://drive.google.com/file/d/1mOdquS ... BBMiK/view .

The result :

root@raspberrypi:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Creative [HDA Creative], device 0: CA0110-IBG Analog [CA0110-IBG Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Creative [HDA Creative], device 1: CA0110-IBG Digital [CA0110-IBG Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM vc4-hdmi-hifi-0 [MAI PCM vc4-hdmi-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM vc4-hdmi-hifi-0 [MAI PCM vc4-hdmi-hifi-0]
Subdevices: 1/1


root@raspberrypi:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Creative [HDA Creative], device 0: CA0110-IBG Analog [CA0110-IBG Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Creative [HDA Creative], device 1: CA0110-IBG Digital [CA0110-IBG Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0


Now to test through a bridge and to see if it actually works for audio .

EDIT : Everything still looks good through the bridge when using one card . On to the actual audio tests .
EDIT 2: Recording works fine through ALSA/JACK, but only when forcing 16-bit (anything higher is distorted), BUT only when connected directly to the PCI Express slot . It does not work at all through my ASM1184E based bridge .

EDIT3 : Tried another bridge setup which consisted of stacked PCI Express to PCI and PCI to PCI Express converters :
01:00.0 PCI bridge: Pericom Semiconductor Device e113
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
and it seems to work through that.

However, if I run it through this unholy abomination of a PCI bridge sandwich, it does not work (aplay -l finds no device) :

pi@raspberrypi:~ $ lspci
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 PCI bridge: Pericom Semiconductor Device e113
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1184e PCIe Switch Port
04:01.0 PCI bridge: ASMedia Technology Inc. ASM1184e PCIe Switch Port
04:03.0 PCI bridge: ASMedia Technology Inc. ASM1184e PCIe Switch Port
04:05.0 PCI bridge: ASMedia Technology Inc. ASM1184e PCIe Switch Port
04:07.0 PCI bridge: ASMedia Technology Inc. ASM1184e PCIe Switch Port
05:00.0 PCI bridge: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG PCIe to PCI Bridge
06:00.0 Audio device: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio]

-[0000:00]---00.0-[01-09]----00.0-[02-09]----04.0-[03-09]----00.0-[04-09]--+-01.0-[05-06]----00.0-[06]----00.0 Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio]
+-03.0-[07]--
+-05.0-[08]--
\-07.0-[09]--

So, I have learned the following thus far :

- The SB1040 sound card plus an ASM1184E PCI Express bridge is currently a no go, at least on the PI 4
- The SB1040 can work on the PI 4 through some bridges (Pericom and PLX ones, see above)
- The SB1040 can work in legacy PCI mode .

[6by9]

The alternate PCIe config? There's an easier route for that by adding "dtoverlay=pcie-32bit-dma" to config.txt. I'm not sure if that is the only change Phil made in the other firmware image.

CA0110-IBG PCIe to PCI Bridge is likely to fail.
PCI was quite x86-centric, and reproduced the old x86 distinction between memory address space and I/O address space. That doesn't translate to ARM at all (where all peripherals are memory mapped), so anything trying to use an I/O bar is going to fail.
I bought a generic PCIe to PCI adapter and failed with all the PCI cards I tried in it - viewtopic.php?p=1772997#p1772997

[Darry]

The alternate PCIe config? There's an easier route for that by adding "dtoverlay=pcie-32bit-dma" to config.txt. I'm not sure if that is the only change Phil made in the other firmware image.

CA0110-IBG PCIe to PCI Bridge is likely to fail.
PCI was quite x86-centric, and reproduced the old x86 distinction between memory address space and I/O address space. That doesn't translate to ARM at all (where all peripherals are memory mapped), so anything trying to use an I/O bar is going to fail.
I bought a generic PCIe to PCI adapter and failed with all the PCI cards I tried in it - viewtopic.php?p=1772997#p1772997

AFAIU, the BIG_PCIE.ZIP was mainly meant to address the too small BAR space for video cards . If I understand you correctly, in my case, setting "dtoverlay=pcie-32bit-dma" would likely have been sufficient to get it to work (please correct me if I have misunderstood. I would need to restore a backup to test this (did not keep a copy of overwritten files in /boot) .
EDIT : "dtoverlay=pcie-32bit-dma" does work instead of BIG_PCIE.ZIP


The CA0110-IBG PCIe to PCI Bridge is part of the sound card (it is an internal bridge, apparently) . It is there even when the sound card is directly connected to the Pi's PCIEX slot and works properly (at least when recording 16-bit audio, which is fine for my purpose).

Just to be extra clear :

this PCI Express sound card WORKS FINE on the PI 4 in two scenarios
- directly connected to the PCI Express slots
- when run through stacked PCI Express to PCI and PCI to PCI Express converters :
01:00.0 PCI bridge: Pericom Semiconductor Device e113 02:04.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21) .

this PCI Express sound card DOES NOT WORK on the PI 4
- when run through an ASMedia Technology Inc. ASM1184e PCIe Switch Port

This leads me to 3 questions/avenues :
a) Can it be made to work through an ASM1184e PCIe Switch Port ?
b) Could it be made to work using a device with a different chipset ?
c) Would it even work through an ASM1184e PCIe Switch Port on an x86/x64 system ?

I am looking at options to test b ) and I a do have a candidate machine to test out c) but am waiting on the required Mini PCI Express to PCI Express adapter to test it out .
EDIT : I ordered a Pericom PI7C9X based adapter with 4 slots . Adapters based on this chip are getting harder to find and I hope the vendor will actually ship me one of those and not one of the now common ASM1184E based units like the one that I already have . I just have a bad feeling .

Any suggestions on how to address a) and/or suggestions regarding b) would be very much appreciated .

On a different but related note, I updated the PI 4 bootloader to the latest one, just in case, but that did not change anything .

[Darry]

I got my hands on a sub 100 $US SFF x86-64 PC, installed Ubuntu 21.04 on it and tried my ASM1184E switch with an SB1040 connected to it .

The result ?
The sound card works fine in this setup, which answers question c) in my previous post : an SB1040 sound card works fine through an ASM1184E PCI Express switch on an x86-64 machine, but not on a PI 4 (yet).

Whether the issue on the PI 4 side of things is due to
a1) the SB1040's HDA driver specifically not working properly through a PCIE switch on an ARM/Pi platform
b1) an issue specific to the ASM1184E on ARM/Pi
c1) an issue with all PCIE switches on ARM/Pi
remains a mystery to me .

I should be able to answer b1) and c1) when I receive my other Pericom based PCI Express switches .

For now, we know that there is at least one PCI Express sound card (Creative SB1040) that works on a Pi 4 when directly connected to it (at least for 16-bit recording).

EDIT : If the issue is present on Pericom based switches as well, I guess I should enable debugging on the HDA driver and open a bug report .

[6by9]

(Generally please avoid editing posts as edits don't make the post unread so comments may get missed)

There is something odd about PCIe switches that needs investigating, and I suspect it is around interrupts (certainly it is interrupt related error messages I see with my switches on some cards).
PCIe on ARM is less mature than on x86, and the two architectures do have some differences (I/O bars being one). It's possible that some things can not be replicated, but it's more likely to be some odd configuration option somewhere.

https://electronics.stackexchange.com/q ... ntx#343218 gives a pretty good description of interrupts on PCIe and how involved it becomes.

[Darry]

(Generally please avoid editing posts as edits don't make the post unread so comments may get missed)

There is something odd about PCIe switches that needs investigating, and I suspect it is around interrupts (certainly it is interrupt related error messages I see with my switches on some cards).
PCIe on ARM is less mature than on x86, and the two architectures do have some differences (I/O bars being one). It's possible that some things can not be replicated, but it's more likely to be some odd configuration option somewhere.

https://electronics.stackexchange.com/q ... ntx#343218 gives a pretty good description of interrupts on PCIe and how involved it becomes.

Thank you for that information and the advice about avoiding EDITs .

I have some interesting info to report as well regarding my tests in the non Pi world, but that could still be useful for Pi users .

Specifically, when I mentioned that the SB1040 worked fine through an ASM1184E PCI Express switch on an x86-64 platform, it was when running a stock non RT patched Ubuntu 21.04 kernel . When I tried an RT (real-time) patched kernel, I got the same error as on the Pi 4 . Essentially (when running jack, but using ALSA directly also fails):

ALSA: poll time out, polled for 1087031 usecs, Retrying with a recovery, retry cnt = 1
ALSA: poll time out, polled for 1087022 usecs, Retrying with a recovery, retry cnt = 2
ALSA: poll time out, polled for 1087024 usecs, Retrying with a recovery, retry cnt = 3
ALSA: poll time out, polled for 1087024 usecs, Retrying with a recovery, retry cnt = 4
ALSA: poll time out, polled for 1087026 usecs, Retrying with a recovery, retry cnt = 5
ALSA: poll time out, polled for 1087026 usecs, Reached max retry cnt = 5, Exiting
JackAudioDriver::ProcessAsync: read error, stopping...


Reverting to the stock Ubuntu kernel on the x86-64 platform fixes it . So, at least on, x86-64, running an SB1040 through an ASM1184E PCI Express switch does not work IF using an RT patched kernel (5.11.0 in my case) .

The question is : would reverting to a stock kernel on the PI 4 allow an SB1040 through an ASM1184E PCI Express switch to work ?

I should be able to answer that in the next few days . In the meantime, I will keep experimenting on the x86-64 platform to try to determine what works and what does not in order to have a baseline to compare with on the Pi .

[Darry]

Well, I have just answered my question regarding the ASM1184E PCI Express switch, an SB1040 and a stock (except for the required CA0110 kernel module) Raspbian kernel configuration : it does not work either . As expected, it does work with the SB1040 directly in PI 4 carrier board's PCI Express slot .

[Darry]

I received some Pericom based PCI Express switches and hooked one up to my PI 4, but the SB1040 does not work any better on it than with the ASM1184E one, unfortunately.

[6by9]

You're doing better than me. I took a punt on a cheapie card which happens to be based on the C-Media CMI8738

Code: Select all

pi@raspberrypi:~ $ lspci -k
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
	Kernel driver in use: pcieport
01:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)
02:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10)
	Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
	Kernel driver in use: snd_cmipci
	Kernel modules: snd_cmipci

So again a PCIe to PCI bridge.
However I get a big kernel paging request error during probe.

Digging through the driver, it wants to do the old fashioned (x86 only) in and out commands to I/O regions. Those fail as they are incorrectly mapped
(detect = snd_cmipci_read(cm, CM_REG_INT_HLDCLR) & CM_CHIP_MASK2; dereferences cm->iobase + 0x0c, to give "virtual address fee0000c" which isn't mapped).

lspci tells me

Code: Select all

01:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 83
	Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort+ >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [78] Power Management version 3
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] Express (v1) PCI-Express to PCI/PCI-X Bridge, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ SlotPowerLimit 0.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <2us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [c0] Subsystem: Device 0000:0000
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-

02:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10)
	Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 83
	Region 0: I/O ports at <ignored> [disabled] <<<<<<<<<<<<<<<<<<<<<<<<< :-(
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: snd_cmipci
	Kernel modules: snd_cmipci

Hmm, https://community.nxp.com/t5/i-MX-Proce ... m-p/473886 seems to imply that it is possible for a PCIe root complex to map I/O BARs, but https://uefi.org/sites/default/files/re ... 15_ARM.pdf says not on ARM. That may be some quirk on the IMX6 then.