On 04/09/2015 06:13 PM, Tony Lindgren wrote:
* Matthijs van Duin <matthijsvanduin@xxxxxxxxx> [150404 21:26]:
Hi all,
To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently
lists the functional clock of the AES accelerator and other crypto
modules to be the (max 26 MHz) main osc. This struck me as rather
unlikely, since the AES module is clocked much higher on other
devices, and such a slow clock would condemn it to being slower than a
software AES implementation. As usual the TRM is silent on the crypto
accelerators and their clock management, but I did some preliminary
tests.
The AES module turned out far from slow. I actually had a lot of
trouble keeping the module continuously fed with data with a simple
non-dma test from userspace, since for most modes of operation the AES
module could even keep pace with a tight loop using 128-bit neon
load/store without even checking its status register for readiness.
Although I haven't been able to get obtain a very reliable measurement
yet as a result, it appears to be clocked at ~200 MHz. This also
matches the fact that it is hooked up to the L3F (which would be
rather pointless if it had a separate low-rate fck).
It seems very likely to me the other crypto modules will also have a
unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and
PKA). This should preferably still be double-checked of course.
Tero, got any ideas about this one?
This seems like just improperly modelled clock data. Looking at some
PRCM documentation, the proper parent for aes/sha seems to be l3_gclk.
pka/rng/des is using l4ls_gclk.
The separate aes/sha clock nodes should just be deleted from the clock
data, and instead use the proper main_clk definition under the hwmod data.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
