Hi Tony, > Am 25.05.2023 um 06:53 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [230524 07:40]: >> Hi Tony and Peter, >> I have upgraded my WIP tree to v6.4-rc3 now. >> >> It is almost working, firmware can be built, and is loaded, subdevices are presented, graph >> has been verified against the working 3.15 version, legacy sound works, amixer settings are >> fine, etc. >> >> The last remaining issue (before the next reveals itself) is that the AE DSP isn't running. >> Playing a sound gets stuck in wait_for_avail() in sound/core/pcm_lib.c obviously waiting for >> some interrupt or DMA trigger from the DSP. >> >> Kernel log/user-space symptoms are: >> >> [ 36.957956] omap-abe-twl6040 sound: playback write error (DMA or IRQ trouble?) >> play WARN alsa: Input/output error >> >> So it may either be a clocking or power issue or something with initialization. >> Very difficult to find. Also symptomatic seems to be that I can hex-dump the /sys/kernel/debug >> files for cmem, dmem, and smem but not pmem. >> >> >> Therefore I am currently going once again through all questionable code where I >> had noted a FIXME to tell that it is obviously not compatible to modern >> kernels and has not yet been fixed. >> >> >> One such place is >> >> https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=sound/soc/ti/aess/omap-aess-pcm.c;h=e9c8b9a00f032f336cac8cbb7e441ce8a7476507;hb=74db6d179bad60cdad29a8704f9e606f8cffccd3#l673 >> >> where there is a "context-lost mechanism" which was removed in v4.18. >> >> Any ideas what that "context lost" is or how it can be fixed in modern kernels? > > There does not seem to be a Linux framework directly usable for this, maybe > the reset framework could be used with addition of some kind of reset status > function. I have not found the reference any more but it appears that there was some code in the omap2 subsystem long time ago. But I may be wrong. > > Initially for your driver, you could simply always restore the context in > runtime PM resume to start with. Ok, that should not harm. > You could also check some driver registers for > context lost status in the driver as the context lost registers are outside > the driver IO range. And after that, using reset framework for context lost > status could be done, maybe by adding support to drivers/soc/ti/omap_prm.c. Ok. I'll look into that. Maybe all this is not the reason why the driver doesn't work but who knows... > >> You may also try or review the full tree: >> >> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/aess-6.4-rc3 >> >> I haven't tried that as a stand-alone without my other local Letux patches for my >> devices, but I think it can run at least on PandaES and omap5uevm after configuring >> omap2plus_defconfig. >> >> Building firmware is best done on the device and running a script like this one: >> >> https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=Letux/root/build-aess-fw;h=0bfe59559e5395fb1e5ad32bbbac676d7665aa22;hb=refs/heads/letux-current >> >> This clones the kernel git repo and tries to build the firmware on the target device. >> I have only tested on Debian 9.13. Other releases may reveal subtle conflicts in system >> include files... >> >> >> Any help (also by readers) to get this beast finally working is welcome. > > Based on a quick glance it looks like pretty much a standard Linux driver > that loads firmware :) Indeed. Most of the work I have done the past months (years?) was to update the firmware load and build mechanisms to use the modern firmware APIs. And track some significant changes in ALSA data structures. I have now tested the current code on the omap5uevm using omap2plus_defconfig which showed that I had to fix two issues. With these updates it works (update force-pushed to https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/aess-6.4-rc3). One issue was an undefined reference to some aess function if CONFIG_SND_SOC_OMAP_AESS was disabled (the default) and the other was the (not) well known limitation of DMA channels to 32. So I have added a modification for the omap5uevm.dts to disable McSPI1 and McSPI4 since they are not connected to the outside world and the pins are used for something else. This frees enough DMA channels so that McPDM can use them. Now it works either without CONFIG_SND_SOC_OMAP_AESS (default) in pure legacy mode as before or with CONFIG_SND_SOC_OMAP_AESS and firmware. There I can use device 11 for the legacy mode but device 5 reports the same error coming from wait_for_avail(). To enable, either add CONFIG_SND_SOC_OMAP_AESS=y or CONFIG_SND_SOC_OMAP_AESS=m to the omap2plus_defconfig. No I wonder if this work can be upstreamed to staging? Including the firmware source code (which makes it much easier to keep them in sync if they are part of the same kernel tree and not a separate project and git repo)? This could allow more developers to work on it. But there is no "sound/staging" subdirectory and moving things to "drivers/staging/aess" would interfere with existing "sound/soc/ti" which is also patched significantly in this branch. So a separate staging location would split up code to too many locations. Best regards, Nikolaus
