On Sat, Sep 02, 2023 at 08:37:16AM +0200, Patrik Dahlström wrote:
Hi Nikolaus,
On Fri, Sep 01, 2023 at 05:26:17PM +0200, H. Nikolaus Schaller wrote:
Hi Patrik,
Am 01.09.2023 um 16:46 schrieb Patrik Dahlström risca@dalakolonin.se:
Hello Nikolaus,
On Tue, Aug 29, 2023 at 06:00:46PM +0200, H. Nikolaus Schaller wrote:
Hi Patrik,
Am 29.08.2023 um 17:44 schrieb Patrik Dahlström risca@dalakolonin.se:
great! I never digged into PM topics and tools...
/* "tick" of the audio engine */
+#if 0 // makes /sys/kernel/debug/omap-aess/pmem inaccessible omap_aess_write_event_generator(aess, EVENT_TIMER); +#endif
printk("%s: 11\n", __func__);
iMac:master hns$
This is in omap_aess_pcm_probe()
Well, a theory could be that this EVENT_TIMER starts the AES DSP in a state where it is not ready to start...
We are getting closer to the road block but still do not understand which material it is off and which crane or explosive we need...
From the function description, I believe omap_aess_write_event_generator() is meant to start the DSP. You can see a call to stop the generator right after in the probe function. If it's not possible to start the DSP, it points to a real problem.
Yes, that made me think that the DSP is not up and running and why I disabled this step.
Hence we either get timeouts when trying to send audio data or get these pmem and other issues.
However, I was able to read the PMEM area without starting the DSP in my test module. Or maybe the startup was hidden from my eyes? hwmods might have activated some clocks behind my back.
I have now tested my module on Linux-6.x and it dumps PMEM area fine. For this test I disabled sound support entirely in the kernel config and only used my test module. I can dump PMEM repeatedly by removing and inserting the module.
There must be something we do while loading some of the audio drivers that make this stop working.
I've been digging into hwmods most of today. I had this idea of writing a minimal kernel module which would simply ioremap() the PMEM memory area and try and read it. Then I could bisect the kernel history to see where things went wrong.
Great idea!
I decided to start with the 4.18 kernel. That's the last kernel version I could find before they started removing hwmods.
It immediately got "Unhandled fault: imprecise external abort".
That occurs if processor or some peripheral tries to access non-existing memory.
Maybe we're missing some memory muxing and that's why this fault happens without hwmods?
Did some digging, and it turns out that OMAP5 did not get the hwmods ported for aess. I copied the definitions from omap_hwmod_44xx_data.c and it all started to work. I could read from the PMEM region without getting any faults any more! Please note that this is without loading any FW so the output is garbage.
I uploaded the code here: https://github.com/Risca/dump_pmem
I'll look into that over the weekend. Since this area is shared with OMAP4 and OMAP5 it should also work on the PandaES.
My experience is that the data in omap_hwmod_44xx_data.c will not be loaded for OMAP5. The Linux-3.8 tree I have is from TI, and that tree have a lot more in omap_hwmod_54xx_data.c. That explains why reading PMEM works in that tree, but not in any mainline tree.
omap_hwmod_44xx_data.c also provides things like OMAP4_RM_ABE_AESS_CONTEXT_OFFSET which is a hint about these context things...
Other things are IMHO available in modern device tree based setups, like mapping of l3/l4 paths and clocks. But this seems to have been removed in v5.6.
OMAP4_RM_ABE_AESS_CONTEXT_OFFSET was last used in arch/arm/mach-omap2/omap_hwmod_44xx_data.c in v5.9 and last defined in arch/arm/mach-omap2/prm44xx.h in v5.15.
Git log shows: c33ff4c864d2b ARM: OMAP2+: Drop unused PRM defines for omap4
commit c33ff4c864d2b2511f43ec11cb23903b957b1159 Author: Tony Lindgren tony@atomide.com Date: Tue Oct 5 10:01:37 2021 +0300
ARM: OMAP2+: Drop unused PRM defines for omap4 These are unused and should be handled by drivers/soc/ti/omap_prm.c driver nowadays. Signed-off-by: Tony Lindgren <tony@atomide.com>
But drivers/soc/ti/omap_prm.c does not talk about AESS or ABE. Now it becomes understandable where our problems come from...
Indeed. I may take a look at omap_prm.c later.
Of course, there is no AESS driver in Linxu-4.18, but this is another clue towards what is missing in Linux-6.x! I decided that I don't have to bisect this any more. It's better to investigate what is the purpose of the aess hwmod. For instance, it calls this function:
/** * omap_hwmod_aess_preprogram - enable AESS internal autogating * @oh: struct omap_hwmod * * * The AESS will not IdleAck to the PRCM until its internal autogating * is enabled. Since internal autogating is disabled by default * after * AESS reset, we must enable autogating after the hwmod code resets * the AESS. Returns 0. */ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
Ok, that is quite some description. This function was also removed in v5.6.
Maybe it is possible to translate all this into ti,sysc-omap2 settings.
I'll contact Tony for help how to translate asap (i.e. tomorrow).
Great idea!
I hope you don't mind that I put kernel@pyra-handheld.com in CC.
I have tried to manually insert equivalent code in the debugfs code (omap-aess-dbg.c), but still no luck in reading from PMEM.
Well, that may be in conflict with other initialization steps.
Yeah, it was a long shot. At this point I'm trying a bit of everything and see what works.
To be continued...
Best regards Patrik
So you have opened the magic door a little bit, so that we can already a glimpse into the treasure chamber behind it :)
:)
Best regards, Nikolaus