On Tue, Sep 19, 2017 at 11:59:25AM +0100, Andrey Utkin wrote:
On Tue, Sep 19, 2017 at 01:29:52PM +0300, Peter Ujfalusi wrote:
I would not try to get 3.8 forward ported, my bnw-3.15 might be a better start. I don't know how big is the diff between the ASoC-dynamic-FW (3.8...3.15) compared to upstream ASoC topology and friends. If there is a big diff, then starting from scratch and using 3.8/3.15 as reference might be the way to go.
Thanks, I will do as you suggested.
So I've restarted forward-porting, using Peter's next-bnw/ti-audio-next_3.15 branch, and had some progress, see https://github.com/andrey-utkin/linux/commits/pyra-aess
Luckily, a bunch of snd_soc_fw_* functions and structs used in AESS source code are already in mainline kernel as snd_soc_tplg_*. It would be tough work for me if it wasn't the case.
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
Also, power management callbacks for suspend and resume have been disabled:
I had to drop suspend and resume callbacks from snd_soc_platform_driver, as this structure doesn't have these callbacks anymore in mainline kernel, see dd63a9c2952e ("ASoC: Remove snd_soc_platform_driver suspend/resume callbacks"). These callbacks are available in snd_soc_component_driver and snd_soc_codec_driver structs. I was about to put omap_aess_pcm_{suspend,resume}() to snd_soc_platform_driver.component_driver, but the fact that these functions take "struct snd_soc_dai *" argument is confusing to me. Again, forgive me my ignorance of sound drivers subsystem :)
I consider this to be not critical as driver can just lack support of suspend/resume temporarily, we'll come back to resolve this when we get it working.
Everybody (especially Peter) is welcome to give comments, advices or add patches. When we fix this last compilation error, we can start testing it in runtime.