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
