Re: omap5 mpu bridge dividers

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

 



On 08/15/2016 11:44 PM, Matthijs van Duin wrote:
It is worth mentioning that based on tests I've done (on an
omap5-uevm), the clock speed of the async L3 bridge appears to be the
bottleneck for traffic between the Cortex-A15 and the L3 interconnect.
As a result, if the bridge clock divider is adjusted as mandated by
the datasheet, L3-heavy workloads will actually perform noticably
worse at OPP_HIGH (bridge @ 1500/8 = 187.5 MHz) than at OPP_NOM
(bridge @ 1000/4 = 250 MHz).

This is an awkward situation.

It would be nice to know what the actual maximum clock speed permitted
for the async bridge is, to have an alternative OPP_HIGH mode where
the bridge divider is left at /4 and the cpu speed only raised as much
as the async bridge will tolerate. I have however not found this
specified in the datasheet.

Also, what are the risks involved in overclocking the async bridge as
is done currently? Will it adversely affect device lifetime? Result in
silent data corruption? Cause protocol errors resulting in deadlock?

That would be an invalid Soc Operation condition -> Looks like a missed configuration path.


It seems curious to me that this problem presumably affects every
omap5 and dra75x/am572x (and possibly dra72x/am571x?) currently out
there, yet no problems have been encountered (or at least been
attributed to it), even though leaving the divider at /4 would seem to
severely overclock it (at 375 MHz). I have myself not observed any
problems while attempting to flood the interface (from/to TILER).

A rare deadlock may actually be an acceptable performance tradeoff for
some applications, especially since the cortex-A15 itself already
includes rare deadlocks, some with performance-affecting workaround
(801819, https://patchwork.kernel.org/patch/6960921/), some with no
workaround (799271).

On the other hand, random silent corruption or a serious reduction in
device POH would be less likely to be considered acceptable by anyone.

Some clarification from TI would be very welcome here.


Hmm.. This does seem on the first look to be a miss in our configuration - i recollect in older evil-vendor-production kernel (circa 3.0/3.4 kernels) we had handled this, but much has changed since then.

Tero is on vacation atm, will have to see how he'd like to handle this.


--
Regards,
Nishanth Menon
--
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



[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