* H. Nikolaus Schaller hns@goldelico.com [230904 18:07]:
Am 04.09.2023 um 08:34 schrieb Tony Lindgren tony@atomide.com: 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.
Hmm sorry I somehow thought it was using a dmtimer. There are references to ABE_GPT5_FCLK to ABE_GPT8_FCLK in the TRM but maybe those are separate and the driver is not tinkering with the timer register directly hopefully.
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.
OK
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/...
So I guess the ick is in the dts the ocp_abe_iclk@528 for omap4 and abe_iclk@528 for omap5. Seems like the driver should request them, I recall that the interconnect target module does not need the ick to access sysc and revision registers.
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.
Hmm the "we don't need separate target modules" patch is wrong, the modules may have separate clocks and power domains, and flushing a posted write to one module does not flush write to the other module. This can lead into hard to track down bugs accessing separate modules. The dts module data I generated from the hardware AP registers for each SoC so the module ranges should be correct.
Hope this helps. Otherwise we have to prepare a cleaned up version of the DTS changes as a patch series.
Yeah nice,
Tony