Neil,
Here's some loooooong info based on the information you sent. They correlate to the answers you provided below plus more.
1. That's good that i2cdetect found the device on the bus. This tells me that ALSA is not setting up the device driver properly (Through the MCASP pins). I noticed in my development, everything has to be just right in order for that to happen.
2. for the MCASP Pins, you are also using "P9.31 " /* mcasp0: mcasp0_axr3 */
3. Both axr2 and axr3 cannot be both inputs. AXR is bi-directional, but the audio codec needs one to be set to transmit (X) and one to be receive (R). Why it ever worked before is a mystery. And setting up their direction is two parts... in the device tree pinmux and in the serialization of the "sound" node of the device tree. I'll give an example below. I've always had to define whether it's a PULLUP or PULLDOWN also and do not believe these can be left free-floating.
4. If you are creating a ".dtbo" file, that is a CAPE OVERLAY, not a DEVICE TREE file (which ends with ".dtb"). It's been stated to move away from CAPE OVERLAYS as they are extremely buggy. You can create a Device Tree and it is used an overlay to the active device tree. The reason you seen what you did is that address "190" was being used by the Kernel and you can't allocate two device pinmux using the same pin address.
5. To see issues, you should be using $ dmesg in your terminal. It outputs the kernel log form /var/logs/ messages. It'll tell you if it's running the TLV320 in there. You can also see if your sound codec is being used by typing $ alsamixer in the terminal. This will bring up a GUI of your sound codec. It should be something different than PulseAudio. Furthermore, add the following line to your overlay in the fragment for sound {.....}, just below the capability line: simple-audio-card,name = "Audio Name I Want";
Whatever you put as "Audio Name I Want" will show up in place of PulseAudio if ASLA is using the TLV320 codec when you check alsamixer.
6. Whenever you change or create a Cape Overlay you MUST run "/opt/source/bb.org-overlays/install.sh". You are doing most of what needs to be done... except rebuilding the /boot/initrd.img-<Kernel build> file (mine is initrd.img-4.19.94-ti-r50). Just running install.sh is all you need to do, it will put everything in the firmware directory and rebuild the image.
So why does it have to be this way?.... Form my understanding, if your new cape is different than the one in that image file or you created a new cape overlay, it will not match what's in that image file. I believe this is done as sort of a checksum to ensure it's a valid overlay for a device. That you cna't just plug anything in and destroy the device. The idea was a cape can be added (connected) and nothing done to the uEnv.txt file and the cape is automatically loaded for use by detecting the cape, putting it's overlay in one of the four cape manager slots and using it to overlay the active device tree. I bet if you check $ dmesg in the terminal, you'll find a line that says it failed to load BB-BONE-AUDI-02.
Device trees are in an entirely different location..... /opt/source/dtb-<current kernel>-ti/src/arm. As an example, mine is /opt/source/dtb-4.19-ti/src/arm. Be weary, they now add the last and newest dtb directories as well. use the one that matches your kernel number in the uEnv.txt file. If you create a device tree, the make file will use dtc to build it from /opt/source/dtb-<kernel>-ti/. Here's an example of how I rebuild device trees and use them. I copy "my_devicetree.dts" to /opt/source/dtb-4.19/src/arm/. usually by just putting the uSD card in my laptop.
$ cd /opt/source/dtb-4.19-ti/
$ sudo touch src/arm/*
sudo touch will change the timestamp of all files (*) in that directory. If not you will get an error when building the device tree for the time being in the future.
$ sudo make src/arm/my_devicetree.dtb
If there are any errors, it'll tell you the line number. fix it.
$ sudo cp src/arm/my_devicetree.dtb /boot/dtbs/<kernel number>/
Then in the uEnv.txt file, I uncomment #dtb= to dtb=my_devicetree.dtb. A device tree does not have to be built into the intird.img file.
Lastly,
In your mcasp{.....} node fragment. You'll see numbers under the serial-dir configuraiton. Those number correlate to te RX you are using. In BB-BONE-AUDI-02, the first line is 0 0 2 1 and correlate to RX0 RX1 RX2 RX3. As you can see RX2 is set as Recieve (or RX) and RX3 is set to Transmit (or TX). Those need to match the input/output direction in the pinmux... which is not the case we see. I never got my development audio board to work until I set the direcitons accordingly. If RX2 is set to RX, then the pin should be an INPUT, if RX3 is set to TX, then it's pin should be an OUTPUT.
I attached an example of the Cape Overlay I did before I moved to using a device tree instead. This worked fine for my prototype device (not the exact same as your audio cape device), but you can see how I had to change things to make it work. If you are using a 3104, just change everything form 3106 to 3104 (I think it's 3 places).
Sorry it was a lot but I learned a lot over the last 2 years working on a linux based Embedded System for my employer. And I like ppl to try and use information to develop on their own.
Does the Audio Cape Device pinout actually match BB-BONE-AUDI-02?