* Andreas Kemnade <andreas@xxxxxxxxxxxx> [230902 10:26]: > On Sat, 2 Sep 2023 09:27:41 +0200 > "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote: > > > Hi Tony, > > we are still struggling with ABE/AESS on the OMAP4/5 (PandaES, Pyra, OMAP5UEVM, BT-200). > > > > Symptoms are that > > * pmem access will be broken after initializing the ABE-DSP > > * it seems the AES DSP is not running (and leads to timeouts when sending audio data to the buffers) > > * boot issues on BT-200 > > > > What we have found is that a TI kernel v3.8 works on the OMAP5EVM but newer kernels start to fail. OK. Sounds like the usual trying to catch up out of tree code with the mainline kernel :) We do have a better infrastructure in place now for using various accelerators with standard Linux generic frameworks now, so it should not be that hard to update the driver code. > > A major observation ist that hwmods have been removed in smaller pieces and the last removal > > was in v5.6: c33ff4c864d2b ARM: OMAP2+: Drop unused PRM defines for omap4 > > > > There are also some other unknown factors in our code where we do not know how to port to modern > > kernels: > > * there is a context lost code but how to make use of it? For now, you can just check if context got lost on runtime PM resume based on some device registers. Linux does not have any framework available right now to make use of the context lost registers. And the context is only lost if the module power domain is shut off, which is mostly not happening with the mainline kernel either. > > * pmem fails unless we disable omap_aess_write_event_generator(aess, EVENT_TIMER); No idea about this one, but this might be doable with generic pwm code now with the dmtimers. See for example how the ir-rx51 is getting phased away and replaced with the generci pwm ir driver. > > It seems as if clocks and code like omap_hwmod_aess_preprogram() is missing. Especially for the > > omap4 we have found no equivalent to aess_fclk which exists for omap5 and dra7. > > Nowhere is a reference using the abe_iclk node. > > > for omap4 I guess the > clocks = <&abe_clkctrl OMAP4_AESS_CLKCTRL 0>; > > in omap4-l4-abe.dtsi should be enough and correcly referencing fclk? Yeah the clocks chould be there and should use addressing like Andreas is showing. The replacement for omap_hwmod_aess_preprogam that should do the trick is sysc_module_enable_quirk_aess() based on AESS module detection. See "aess" in ti-sysc.c. If the AESS module has different revision register values other than 0x40000000, then new entries need to be added. Not sure which dts file(s) to look at in your git tree, maybe send some RFC patches to the mailing lists on adding support? Regards, Tony
