Hi,
On 2017-10-08 16:35, Andrey Utkin wrote:
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.
The soc-topology is the evolution of dynamic firmware.
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.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
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 :)
As commit dd63a9c2952e suggests, the device suspend/resume should be used, but it is not a show stopper.
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.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki