Hi Tony,
Am 04.09.2023 um 08:34 schrieb Tony Lindgren tony@atomide.com:
- Andreas Kemnade andreas@kemnade.info [230902 10:26]:
On Sat, 2 Sep 2023 09:27:41 +0200 "H. Nikolaus Schaller" hns@goldelico.com 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.
Well, the driver seems to be working and upgraded as good as possible - except PM which should be managed by core.
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.
Ok, so we do not have to focus on that at the moment.
- 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.
This is not PWM. It writes to some register shared with the AESS DSP and we assume that the DSP firmware should be started. I have put Péter on CC, maybe he knows something.
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.
Well, according to my analysis the fclk may be there but the iclk is missing or not initialized. That could explain why we get L3 problems as soon as we try to start the AESS-DSP.
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.
Ah, I see. I have compared sysc_module_enable_quirk_aess() and omap_hwmod_aess_preprogam() and they seem to be equivalent (assuming the base addresses are resolved in the same way).
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?
Well, the patches itself are not cleaned up, but the result is what we think is clean (so a diff to v6.5 will show what we have changed):
Mainly of interest with changes compared to upstream are: https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/... https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/... https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/... https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/...
The key observation is that the abe_iclk references in the DTS seem to be nowhere referenced (which may or may not be an issue):
https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/... https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/...
The branch where all changes are sitting can be inspected here:
https://github.com/goldelico/letux-kernel/commits/letux/aess-v12?after=567e9...
They are all tagged ARM: DTS: omap4 or omap5.
Hope this helps. Otherwise we have to prepare a cleaned up version of the DTS changes as a patch series.
Best regards, Nikolaus