Re: ABE/AESS on modern kernel: clocks, hwmods etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Tony,

> Am 05.09.2023 um 08:12 schrieb Tony Lindgren <tony@xxxxxxxxxxx>:
> 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):
> 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.

Yes, that is what I suspect but I don't know how to request them.

>> The branch where all changes are sitting can be inspected here:
>> 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

According to several TRM versions this is only one module (the Audio Engine AE module) which provides these RAM areas.
"The AE subsystem includes an AE and has the following on-chip memories available: 64-KiB data memory (DMEM); 6-KiB coefficient memory (CMEM); 8-KiB program memory (PMEM); and 18-KiB sample memory (SMEM)."
"Figure 13-1. Audio Back End" seems to integrate the whole AE into a single (target) module being part of the ABE together with McPDM, McBSP, WDT, GPTIMER.

There seems to be no separate dmem, cmem, smem, pmem modules which need hwmod or sysc control.

See also Table "Table 2-8. ABE DSP Memory Space Mapping" in the OMAP5432 TRM where DMEM and CMEM are called "Memory".
But you are right the SMEM and PMEM are called "Module" like for example MCBSP2. But there is also an AESS configuration "module".

Finally "Table 3-243. CD_ABE Modules Clocks Association" seems to be quite cleart that there is AESS_GFCLK and ABE_GICLK.
And clocks for all other modules - but no special ones for the memory blocks.

Maybe "Table 3-245. CD_ABE Modules Clock-Management Modes and Control" and "Table 3-246. CD_ABE Modules Slave Clock-Management Modes and Control"
give more hints about the CLKCTRL we need:


Table "Table 3-1074. ABE_CM_CORE_AON Register Mapping Summary" (all from OMAP5 TRM) also may be helpful.

> 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.

Finally all this was based on some 3.15 DTS entry by TI which has a single ti,hwmods = "aess"; entry.

I have not found a link to the original but have a copy in our tree:;a=commit;h=ca9ee9532104eac5cfee1bd77a2bf6296cbec648

It seems to be impossible to handle this with multiple target-modules.

>> Hope this helps. Otherwise we have to prepare a cleaned up version of the DTS changes as a patch series.
> Yeah nice,

I have done this so that only the AESS specific DTS changes remain and I will post a short RFC series soon.
This should make it easier for doing reviews.

BR and thanks,

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux