Am 10.12.2019 um 16:48 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

Am 10.12.2019 um 16:10 schrieb Michael Mrozek <EvilDragon@openpandora.org>:

Am Tue, 10 Dec 2019 10:24:03 +0100 hat H. Nikolaus Schaller
<hns@goldelico.com> geschrieben:

Hi,

I guess AESS couldn't be made to work?  
We know it can likely work, but we don't know how to do it.
If you want to build a kernel without any AESS contaminations, just
replace sound/soc/omap/ and sound/soc/ti by upstream code. That
should all be code tested by upstream developers and remove the extra
audio devices created by our AESS attempt.

Ah, so those extra audio devices that are segfaulting the kernel are
actually the ones that try to make use of AESS?

Yes.

So, if I understand it correctly:

* AESS is supported by TI in older kernel versions.

Yes. At least for OMAP4.

* Newer kernel versions don't support it anymore and work on the driver
has been made to fix this.

Yes. But Kernel APIs have changed over time (functions have been renamed,
structs have been reordered, macros and constants changed) and nobody from
our team did look to really fix issues. I just did keep the compiler from
stopping with errors. So it got more and more broken.

* Right now, the driver loads the firmware

Well it tries, but does not find one. Usually it would then fail completely.
I have added a hack that it still continues.

and creates these extra
audio devices,

I think they are for intermediate stages of the audio pipeline, similar to
the image signal processor (ISP) for the OMAP3 camera.

but accessing the these devices leads to a kernel
segfault.

Is that correct so far?

Yes.

So what's left is trying to find out why the segfault happens when we
try to use the AESS firmware, correct?

There are likely multiple segfaults or other bugs hidden by it.

Has anyone ever tried to compared how an old kernel with AESS works
compared to the latest one with crashing AESS?

Probably no, because there is no known kernel tree with working AESS.

We just tried playing some emulation on the Pyra - and PulseAudio
needed a whopping 38% CPU power simply to play the audio.
aplay with a 32 bit 4 channel 96000Hz wav takes 0.7-1.0% cpu, so
it's pretty clear that audio is TOTALLY unusable without hardware
mixing.
So we NEED to get that working. Does anybody know someone who would
be capable of that? Even if he needs to be hired and paid, but
sound is unusable at the moment.  
Well, I could offer myself since I already have a basic understanding
on what AESS and ALSA is about and the data sheets. But I am not the
über-specialist for Linux Audio. Just a specialist for fixing bugs.
So it needs some time to fill the knowledge gaps by studying code and
more data sheets.
I stopped voluntarily looking into the audio driver (and TILER) a
while ago since I have much higher priority topics. So we are
carrying along code where we know it is broken.
How fast I can do something depends on the priority you can give a
topic by your budget.

Well, I can't spend thousands of EUR if this doesn't lead to any
results.
But as mentioned multiple times, I have no problems paying someone to
fix the remaining issues we still have open.

So if you think it's possible for reasonable time / money, let me know.

Well, the question is what is reasonable. For each unexpected single bug
it takes me usually 3 full working days to identify the reasons and work
out and test and debug a fix so that it is acceptable upstream. This may
include setting up user space code to be able to test something and as a
first step tryng to understand what the code did intend to do with an
older kernel and search for the newest APIs doing the same effect with
different function calls.

I would estimate that there are ca. 5-10 of this type hidden behind the
first one leading to a segfault which makes 15-30 hours full time work.

Sorry, that was a wishful miscalculation...
3 full working days with 5-10 such issues is  ca. 100 - 200 hours.

Maybe someone raises his/her finger and does fix it in less time?

BR,
Nikolaus
Kernel mailing list
Kernel@pyra-handheld.com
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel