Re: [RFC PATCH 0/3] Enable 1GHz support on omap36xx

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

 



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.

> 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.

So:
step 1: get 1GHz stable
step 2: turn it off on 800MHz rated chips

BR,
Nikolaus





[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