OMAP4/5 AESS on v6.4

OMAP4/5 AESS on v6.4

[H. Nikolaus Schaller]

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?


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.

Best regards,
Nikolaus

Re: OMAP4/5 AESS on v6.4

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [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.

Initially for your driver, you could simply always restore the context in
runtime PM resume to start with. 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.

> 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 :)

Regards,

Tony

Re: OMAP4/5 AESS on v6.4

[H. Nikolaus Schaller]

Hi Tony,

> Am 25.05.2023 um 06:53 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [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

Re: OMAP4/5 AESS on v6.4

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [230525 08:34]:
> > Am 25.05.2023 um 06:53 schrieb Tony Lindgren <tony@atomide.com>:
> > 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.

So reset_control_status() could maybe return -EIO error if context was lost.
Or maybe something like reset_control_context_lost() could be implemented.
Needs to be discussed on the related mailing lists of course. Then omap_prm.c
just needs the context lost registers mapped, and consumer drivers can check
context lost status from the reset framework.

Regards,

Tony

Re: OMAP4/5 AESS on v6.4

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [230526 05:09]:
> * H. Nikolaus Schaller <hns@goldelico.com> [230525 08:34]:
> > > Am 25.05.2023 um 06:53 schrieb Tony Lindgren <tony@atomide.com>:
> > > 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.
> 
> So reset_control_status() could maybe return -EIO error if context was lost.
> Or maybe something like reset_control_context_lost() could be implemented.
> Needs to be discussed on the related mailing lists of course. Then omap_prm.c
> just needs the context lost registers mapped, and consumer drivers can check
> context lost status from the reset framework.

Oh looking at the dts files, we're not passing the register offset to the
prm reset controller instance. So the binding #reset-cells = <2> would be needed
where the first one is reset controller offset and second one is the bit in the
context register. Seems doable though if we want to make reset framework
support hardware triggered reset status.

Regards,

Tony