The Bela cape rev C comes with a ES9080Q 8-channel DAC and a TLV320AIC3104 stereo codec. The former has no support on Linux, while the latter is well supported. This project involves:
writing a driver for the ES9080Q, which interacts with existing McASP and DMA drivers
have the ES9080Q and TLV320AIC3104 show up as a single ALSA device with 2 inputs and 10 outputs. Explore whether this can happen via a simple wrapper in the device tree or requires a dedicated driver.
To ensure I understand the project goals clearly. I have illustrated ALSA, Linux Kernel and Hardware Integration diagram.
The driver will be part of the ALSA SoC (ASoC) framework. The block that highlighted with red color indicates the task for this project.
Task:
ES9080Q DAC Codec Driver
I2C Communication
Device Init and Configuration
Setting up the TDM
Machine Driver
Registers the S9080Q and TLV320AIC3104 as a single ALSA device
This is missing the codec driver for the ES9080Q. Also, the communication between the McASP and the ES9080Q is via TDM, not I2C.
This is about drivers that use ALSA and DMA, no PRU involved.
In the first instance, a regular non-Xenomai Linux driver is the objective. If we select the longest duration for the project, then we could add a Xenomai port to the ALSA driver. This will need to be modified to use Xenomai-friendly DMA and IRQs.
I am not familiar with that one, but it looks pretty outdated? I think the ideal solution is an ALSA driver that can also handle out-of-band requests at Xenomai priority. I think that’s the foundational model of Xenomai-4 / evl kernel drivers.
Thanks. Looks good overall, I think this can be a strong proposal.
Comments on ef6dbab53f62ad426740a9fae33e97ff030685b5:
figure 1 the ASOC Driver box is missing the tlc320aic3x driver
“pathes” should be “path”
“For es9080q codec driver parameters configuration. I will refer to the driver documentation and the implementation in Bela’s code core/Es9080_Codec.cpp” . That implementation is limited to as specific use case. You may want to use the ESS ES9080Q datasheet as a further source of information. I know you included that in the resources at the bottom, but you will need it much earlier than “If I get stuck on my project”
"which which is actually " remove one ‘which’
the title “Platform Drivers Implementation” makes it look like you will be working on the platform driver, but I don’t think any work is needed there. You may make that clearer in the paragraph that you’ll be using TI’s existing drivers
figure 4 "sound card schematics’ I don’t understand why you have both DAI link1 and DAI link2. There’s no tlv320dacxxxx chip on the board, is that a way of referring to the dac part of the tlc320aic3x ? but then why is there also a tlc320aic playback DAI link? I suspect one should go
“Uses I2S for 2-channel input/output (AUDIO_INL/R and HPL/R).” There’s also a line output available on board which is driven by the same digital data as HPL/R. Also, when running alongside the ES9080Q, this is actually running as TDM (not I2S) because the TLV320AIC3104 is generating the bitclock for both codects at 256 clocks per frame. Similarly in the “Sound Card Definition”, it should actually be the tlv320aic310x the one generating the clocks. That’s the currently used configuration. Other configurations may be possible with the current wiring, but we should probably start from the one that’s already in use on Bela.
I like the idea of benchmarking Xenomai-3 vs Xenomai-4, but that is not a high priority. I think Xenomai-4 should be privileged as it should be easier to port a driver to it and Xenomai-3 would require a complete rewrite which may be outside the scope of this project. It’s fine to keep it in there for the proposal, but maybe mark Xenomai-3 as a stretch goal?
“Linux kernel 5.15” is a bit old. We should target the latest Xenomai-4 supported kernel available.
Timeline:
“familiar” should be “familiarize with”
it seems over ambitious to have ES9080Q driver implemented on week 1 and under ambitious to only progress on configuring one subsystem per week on weeks 3, 4 ,5. I think it’s more 3 weeks doing the ES9080Q and 1 week configuring the three subsystems. Anyhow, on balance it seems reasonable to reach a working ALSA driver by midterm. That would allow enough time for back and forth with the maintainers to make sure by the end of the project the driver is ready to marge. I would take out the RTDM stuff and give yourself more time to work on Xenomai-4/EVL instead.
Great work overall, make sure you submit by the deadline!
