*bump* On 16 August 2016 at 15:44, Nishanth Menon <nm@xxxxxx> wrote: > > 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 That doesn't actually answer though >> 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. Any news? Matthijs -- 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
