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!
