• CTAG-ALSA
  • CTAG face support in Linux 5.x kernel

An update: it works-hacked. https://github.com/giuliomoro/linux/tree/5.10-ctag-hacks

Notes first:

Workflow

Quick reload of modules: you need to unload and reload them in this order:

sudo modprobe -r snd_soc_davinci_ctag_face_2_4
sudo modprobe -r snd_soc_ad193x_spi
sudo modprobe -r snd_soc_ad193x
sudo modprobe -r snd_soc_davinci_mcasp
sudo modprobe snd_soc_davinci_mcasp
sudo modprobe snd_soc_ad193x
sudo modprobe snd_soc_ad193x_spi
sudo modprobe snd_soc_davinci_ctag_face_2_4

My current fast iteration script is as follows:

on the build machine quick-build.sh in kernel/ is:

#!/bin/bash
. ../../scripts/config.sh && make ARCH=arm -j$(nproc) CROSS_COMPILE="${CACHED_CC}"  modules
set -x
rm -rf  sound/soc/{ctag,codecs,ti}/snd-*.xz
xz -k sound/soc/ti/snd-soc-davinci-mcasp.ko
xz -k sound/soc/ctag/snd-soc-davinci-ctag-face-2-4.ko
xz -k sound/soc/codecs/snd-soc-ad193x.ko

on the target I have

#!/bin/bash
set -ex
REMOTE=bui
REMOTE_PREFIX=/lfs/tmp/kernel/sound/soc/
LOCAL_PREFIX=/lib/modules/5.10.145+/kernel/sound/soc/
MOD_EXT=.ko.xz
MODULES_PATHS="ti/snd-soc-davinci-mcasp codecs/snd-soc-ad193x ctag/snd-soc-davinci-ctag-face-2-4"
#MODULES_PATHS="codecs/snd-soc-ad193x ctag/snd-soc-davinci-ctag-face-2-4"
MODULES=
for a in $MODULES_PATHS; do
	MODULES="$MODULES $(basename $a)"
done
MODULES="$MODULES snd_soc_ad193x_spi"
RSYNC_LIST=
for a in $MODULES_PATHS; do
	RSYNC_LIST="$RSYNC_LIST $REMOTE:$REMOTE_PREFIX/$a$MOD_EXT"
done

rsync -av $RSYNC_LIST ./
sudo modprobe -r snd_soc_davinci_ctag_face_2_4
sudo modprobe -r snd_soc_ad193x_spi
sudo modprobe -r snd_soc_ad193x
sudo modprobe -r snd_soc_davinci_mcasp

for a in $MODULES_PATHS; do
	sudo cp $(basename $a)$MOD_EXT $LOCAL_PREFIX/$a$MOD_EXT
done
for a in $MODULES; do
	sudo modprobe $a
done

Then from the target I can run:

ssh bui "cd /lfs/tmp/kernel/ && ./quick-build.sh" && ./deploy.sh  && sleep 0.5 && aplay -D plughw:CARD=C8CH,DEV=0 ~/out.wav

(the above is mostly for my future self).

Driver and codec issues

Most of the entries in the dtb are ignored. As far as I can tell from grep ing through sound/, mcasp-controller-bit-delay-tx and mcasp-controller-bit-delay-rx from the device tree are not handled anywhere.

The AD1938 seems to mostly ignore the values in SDATA delay (DAC Control Register0 bits 5:3, AD193X_DAC_CTRL0) when in TDM mode. I don't see this explicitly stated in the datasheet anywhere. However it seems to be affected - at least to a certain extent - by SDATA delay (ADC Control Register 1 bits 4:2, AD193X_ADC_CTRL1), which makes little sense to me.

I found out experimentally that, when the DAC is set to TDM mode (and it ignores the DAC SDATA delay in AD193X_DAC_CTRL0 and with the ADC SDATA delay in AD193X_ADC_CTRL1 set to the default value of 1), it expects a data format that corresponds to what the McASP would call "data_delay = 2" ( i.e.: the word starts not at the same time as the frame clock ("data_delay = 0"), not on the first bitclock after the frame clock ("data_delay = 1"), but on the second bitclock after the frame clock ("data_delay = 2"). The data_delay property in the McASP's XFMT register (DAVINCI_MCASP_TXFMT_REG), however, can only be set to 0 or 1 in davinci_mcasp_set_dai_fmt(), and it currently can only be set to 2 via a hack, or perhaps calling mcasp_set_bits() from the driver after davinci_mcasp_set_dai_fmt() has been called. I didn't investigate that part.
https://github.com/giuliomoro/linux/commit/dc06cf9e383d265ebb3c055ddd2ac87a8fe7e60f shows this solution (via hack), which would also break any other driver using McASP.

An alternative, which leverages the fact that somehow the DAC format is affected by the ADC format register is in https://github.com/giuliomoro/linux/commit/0bf82f6cf053d8d6bfa600e04f60d12db17dc92e. This doesn't break any core mcasp stuff, but it leverages a poorly understood undefined or undocumented behaviour. Good enough for a PoC.

Known issues

Probably a better approach is needed, but this codec behaves so weirdly that I am not sure it's worth the pain.

I noticed that with either version of the driver above, if you stop/restart the aplay enough times, you may get that the output's amplitude becomes smaller, almost half, as if it was shifted by one bit to the right, but I don't see any bit shifting on the McASP side. If you unload and reload the snd_soc_davinci_ctag_face_2_4 module at that point, the amplitude increases slightly. If you also unload and reload (in order) snd_soc_ad193x_spi, then it goes back to normal. It may well be some issue with how the codec is handled there .. for instance: is it being reset appropriately? I didn't look at it.

You can easily reproduce the issue letting this running:

while sleep 0.1; do aplay -D plughw:CARD=C8CH,DEV=0 ~/out.wav & sleep 0.5; killall -2 aplay; done

A workaround is to always run

sudo modprobe -r snd_soc_davinci_ctag_face_2_4
sudo modprobe -r snd_soc_ad193x_spi
sudo modprobe snd_soc_ad193x_spi
sudo modprobe snd_soc_davinci_ctag_face_2_4

after opening/closing the soundcard (via aplay or otherwise).

    giuliomoro looking at your overlay, is there a delay of 1 for the McASP controller and another 1 for the interface (making a total delay of 2?). It does seem that the overlay would be the way to make this work. Reviewing the driver kernel code in the BB and TI kernels there’s not much difference (I notice the _priv struct is slightly different).

    My approach is based (following in parallel what you’ve been doing) on using buildroot to create a very small firmware for my project, removing all the unessary items/modules etc as I only need Ethernet and CTAG and GSTreamer plus ALSA.

    Ideally I’d have the CTAG driver compiled in not as a module.

      siraaris ooking at your overlay, is there a delay of 1 for the McASP controller and another 1 for the interface (making a total delay of 2?).

      As mentioned, I think many of the entries in the dtb are ignored. I could not manage to generate any difference on the McASP side (i.e.: observable changes in the delay between frame clock and data) or on the codec side (i.e.: observable changes in the registers set by the driver (as printed or changes in the analog signal generated by the DAC) when changing any of ti,audio-codec-bit-delay-dac or ti,audio-codec-bit-delay-dac = <1>. Inspecting the driver's source I don't see where those would be read anyhow and - interestingly - inspecting the commit log (-p) of the relevant files doesn't show me these have ever been used anywhere (as far as I can tell).

      siraaris Ideally I’d have the CTAG driver compiled in not as a module.

      Even when it is, you should still be able to bind/unbind it if needed, i.e.::

      echo  "ocp:bone_sound" | sudo tee /sys/bus/platform/drivers/snd_ctag_face_2_4/unbind
      echo  "ocp:bone_sound" | sudo tee /sys/bus/platform/drivers/snd_ctag_face_2_4/bind

      (I think). But sure it would be best to just fix the driver so it doesn't require this step.

      17 days later

      Just a quick note, I spent some time getting a Yocto setup working with 5.10-ctag-hacks. Had to combine the CTAG overlay into the device tree am335x-boneblack.dts as I couldn't get loading of DTBO's working.

      Did a very quick test, and confirm driver loading, and aplay/arecord seem to behave as expected on initial inspection.

      I think that I'll be able to progress with the POC and get a better sense and actual listening of the project during the end of year break - thank you.

        siraaris I couldn't get loading of DTBO's working.

        That's normally done in uboot.

        a year later

        I've been trying to follow along. I've compiled new kernel modules for the BBB bullseye release 11.7 with the 5.10-ctag-hacks and the API changes.
        If I don't include the DTBO overlay in the eEnv.txt then the sound card shows up in ALSA but its not really working.
        If I actively enable the DTBO overlay the in uEnv.txt the sound card doesn't show up at all in ALSA.

        @siraaris It seems you got things working. I understand you integrated the CTAG overlay into the device tree am335x-boneblack.dts, correct? Is there any way you could share you merged device tree file?
        Did you have to make further changes to the driver/codes as proposed by giuliomoro ?

          amessner If I don't include the DTBO overlay in the eEnv.txt then the sound card shows up in ALSA but its not really working.
          If I actively enable the DTBO overlay the in uEnv.txt the sound card doesn't show up at all in ALSA.

          can you show the content of uEnv.txt in either cases?

            giuliomoro
            I've attached the uEnv.txt where I see a sound card in ALSA but it doesn't actually use the device tree overlay for the CTAG face -> uEnv_original.txt
            I can run "speaker-test -D hw:0 -c 2 -r 48000 -t sine -f 1000" (please note channel count 2). If I try any higher channel count it doesn't work. And even with 2 channels I don't hear anything on any of the CTAG outputs.

            I've tried multiple configurations, the last one I tried is actually taken from one of your earlier posts. With this uEnv.txt I don't see a sound card in ALSA at all -> uEnv.txt.

            I found that adding the device tree overlay for CTAG to the uEnv.txt OR disabling any of the overlays for video, audio, etc will cause the sound card to disappear

            uenv.txt
            2kB
            uenv-original.txt
            2kB

            .

            OK I managed to have a look at this. You need this branch in /opt/sources/dtb-5.10-ti and then do make && sudo make install to put the update base device tree and overlay in place. At that point those will be loaded OK, but no soundcard will appear because the driver is not there and so you need to build and install the driver, as you can tell because modprobe snd-soc-ad193x snd-soc-ad193x-spi snd-soc-davinci-ctag-face-2-4 fails. I have not repeated the build and install procedure because it should be the same as previously and also I don't have machine to build it on with me right now, but hopefully you can.

            Thank you @giuliomoro.

            @amessner based on the above activity I dug out my BBB/CTAG and am going to attempt to rekindle where I got to previously - might be a week or so.

            Ok I made some progress.

            I used the latest Bullseye Image for the BBB (kernel 5.10.168-ti-r72) as a base.
            Then patched (https://github.com/anbraten/beagle-bone-builder/tree/master/resources/ctag-2.4) and compiled the drivers for snd-soc-ad193x, snd-soc-ad193x-spi and snd-soc-davinci-ctag-face-2-4, copied them over and confirmed that they load.

            Then I updated the uEnv.txt (see uEnv.txt of my last post)

            Now I can play sounds on 2 channels, but not on the other 6.
            If I try recording something it also doesn't "really" work. Sometimes I get a very noisy file, sometimes nothing.

            Did anyone get as far as to record something successfully? Or did you just test by playing back a test wav file?

            @giuliomoro if I try to use your device tree branch then the image won't even boot anymore.

              I won't be able to have another look until some point next week.

              amessner if I try to use your device tree branch then the image won't even boot anymore

              to troubleshoot that you'd need to get a serial log from the UART0 port on the BBB.