On Mon 26 May 2014 01:32:08 AM CDT, Tero Kristo wrote: > On 05/24/2014 12:07 AM, Mike Turquette wrote: >> Quoting Nishanth Menon (2014-05-16 03:45:57) >>> Hi, >>> >>> This patch series has been carried over in vendor kernel for quiet >>> few years now. >>> >>> Unfortunately, it was very recently re-discovered and upstream kernel >>> is noticed to be broken for OMAP5 1.5GHz - at least we are operating >>> DPLL at frequency higher than what it was intended to be when CPUFreq >>> is enabled. Thankfully, with nominal voltage(we dont use AVS yet in >>> upstream for the mentioned platforms) and margins in trimming, we >>> have so far not crashed - but I strongly suspect this might be some >>> boundary case survival. >> >> DCC also exists in OMAP4. In some cases customers used it, in other >> cases we just ran the PLL way out of spec and the mpu_clk would divide >> by 2. >> >> Is this broken for OMAP4 as well? > > Yes, its broken. This series does not address the OMAP4 needs for it, > but can be expanded later by just defining a proper clock type with > OMAP4 specific DCC rate limits etc. for it. We would need properly > functioning DVFS for OMAP4 panda first though I guess... (support for > the TPS regulator.) Panda does not need DCC. Panda uses 4430 and Panda-ES uses 4460. neither of which need DCC (DPLLs are trimmed for required frequencies there) - 4430 never had DCC, 4460 had broken DCC. 4470 (which is not upstream and does not have a panda variant) is the only one needing DCC at higher frequencies, and that needs an entirely different scheme(compared to OMAP5+) as mentioned by Tero if 4470 ever gets supported upstream. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
