[Letux-kernel] 1.5GHz problems

Matthijs van Duin matthijsvanduin at gmail.com
Tue Aug 2 02:55:26 CEST 2016


I'm missing the initial part of the thread and haven't read it all in
detail yet, but I can offer my first thoughts:


I recently posted that I discovered that the Cortex-A15 subsystem's
async bridges to the L3 and ABE interconnects are being overclocked
(according to the datasheet) when the cpu is run at 1.5 GHz.  The OS
is supposed to reduce their clock dividers prior to switching to 1.5
GHz clock, but this did not seem to be happening.

If you check CM_MPU_MPU_CLKCTRL (0x4a004320), bits 25 and 26 are zero
by default, which means L3bridge = cpu/4 and ABEbridge = cpu/8. They
should be set to 1 before going to 1.5 GHz according to the datasheet,
which makes the dividers /8 and /16 respectively. Unfortunately though
this means that at OPP_HIGH they are clocked 25% slower than at
OPP_NOM, and (based on testing) the bridge clock speed actually seems
to be the bottleneck for L3 access. Yuck.

No idea why you'd have problems with it though when the uEVM seems to
be fine with the L3 bridge apparently being overclocked by 50% (!!!).

This theory does have the benefit of being dependent specifically on
cpu clock frequency and not on how heavily the cpu is actually being
exercised. For everything else I can think of the only explanation
would be "it just happens to be triggered by the way you exercise the
hardware" which seems very weak.  E.g. the cortex-A15 does have a few
"nice" errata resulting in core deadlock. Of course it doesn't hurt to
try enabling CONFIG_OMAP5_ERRATA_801819 if it isn't already (see
https://patchwork.kernel.org/patch/6960921/ ).


Have you been able to check using JTAG in what sort of state the
core(s) or SoC in general are?  Even if the ARM subsystem is totally
locked up, if you can connect to DAP then you can inspect things like
PRCM registers and use I2C to check the configuration of the PMIC. (if
you need it, I have some javascript helper code for CCS debugserver to
perform I2C requests)

Matthijs


More information about the Letux-kernel mailing list