On Thu, Aug 15, 2019 at 5:16 PM H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > > Hi, > > > Am 15.08.2019 um 17:41 schrieb Adam Ford <aford173@xxxxxxxxx>: > > > > On Wed, Jul 31, 2019 at 8:42 PM André Roth <neolynx@xxxxxxxxx> wrote: > >> > >> Hi all, > >> > >> the current mainline kernel does not provide support for running > >> omap36xx based boards at 1GHz for chips like DM3730 where this would be > >> supported. It has been discussed many times, I hope you do not mind me > >> bringing this up again ;) > >> > >> I found some proposed patches by Nishanth Menon from TI [1] and a > >> statement [2] that drivers for the Voltage processor and controllers are > >> needed to properly run those chips at 1GHz using Adaptive Voltage > >> Scaling (AVS) and SmartReflex (SR). > >> > >> As there are drivers for VP and VC in the kernel, I tried to figure out > >> how to enable them and found a PATCH 1/3 which enables SR in the TWL > >> driver. However, the order in which PM, SR and TWL are initialized or > >> probed did not match, which I was able to fix with PATCH 2/3. In the end > >> calling omap_sr_enable in PATCH 3/3 finally enables SR and my board > >> seems to run fine at 1GHz (not battery powered, full performance > >> required). > >> > > > > Question: > > > > Not all 36xx SoC's can do 1GHz. I know there is a register that we > > can read on the OMAP36 to determine its max speed, but I wasn't sure > > how that would play into cpufreq or whatever is going to be driving > > the dynamic voltage and frequency scaling. Are going to have to > > expect people who have the 1GHz version to use a custom device tree? > > I had discussed off-list with André the idea that omap36xx.dtsi gets > an additional 1GHz OPP. > > But there is some driver code that checks if the "speed binned bit" > is not set for 1GHz and eliminates all OPPs above 800MHz by code. > > I tried to get such code into drivers/cpufreq/ti-cpufreq.c but > gave up when I found that this is not used for the omap36xx. > I then wonder if we could add the 1G OPP to the device trable and make it as 'disabled' Something similar was done for the da850 (think omap-l138 or AM1808) https://lore.kernel.org/patchwork/patch/1061044/ If the 3-patch series already submitted is accepted, having the foundation for the 1GHz OPP shows them what they need to make it work. I am really exited about what you are doing. > > AFAICT, there is an updated opp-v2-ti table which has a 'supported' > > entry which appears to read registers to determine which opp's are > > available for the am33xx, but I don't think this applies to the > > omap36. Do we need something that like for this? > > Yes. I also noticed that there is an old style OPP format and a new > style which allows to make the OPP list depend on conditions like am33xx. > All described in Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt. > > To me it looks as if this opp-v2-ti table is what we need for omap36xx.dtsi > as well to manage the speed-binned bit of DM3730. To me it looks sufficiently > similar to an "eFuse" bit. But I didn't look into the details of the > opp-v2-ti format, because all that is a second step after getting 1GHz stable > on 1GHz capable chips. I looked into this once, but I couldn't figure out how to interpret the "opp-supported-hw" entries. If you keep me in the, loop, I'm more than happen to help where I can and/or test when possible. adam > > So: > step 1: get 1GHz stable > step 2: turn it off on 800MHz rated chips > > BR, > Nikolaus >
