Re: beaglebone: changing cpu frequency

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On Aug 1, 2013, at 3:06, Matt Thomas <matt%3am-software.com@localhost> wrote:
> On Jul 31, 2013, at 11:54 PM, Radoslaw Kujawa 
> <radoslaw.kujawa%c0ff33.net@localhost> wrote:
> 
>> 
>> On 1 Aug 2013, at 3:03 AM, Matt Thomas <matt%3am-software.com@localhost> 
>> wrote:
>> 
>>> I still need a good method to get the powersource from the tps65217pmic so
>>> I can limit the frequencies when power is limited.
>> 
>> 
>> The power source is checked in the driver, but it's only used to print the 
>> current source during attachment. The value of this register is never 
>> checked again later.
>> 
>> I think we have at least two ways to do it:
...
> 
> I think the system should automatically drop cpu speed to 550MHz to be safe.
> Then let powerd figure out if it should be increased.
> 
> Maybe add a PMFE_POWER_CHANGED event and I can use pmf_event_register to 
> monitor
> for it when your driver does a pmf_event_inject with it.

Note, however, that for the BB Black, the SRM has a power consumption test with 
the CPU
running at 1000 MHz with the HDMI active, the USB port driving a hub and with 
the other
USB port and the SD card slot in use, which found the maximum current draw to be
485 mA.  The BB Black doesn't necessarily need the CPU frequency dropped when 
running
on USB peripheral power, only the BB does, but I'm not sure how one would tell 
them apart
in software.

On the other hand, it is also possible to have a big enough peripheral taking 
power from
the USB host port (assuming there's a driver for it some day) or the expansion 
connectors
that there is no way to run at all on the power available from the USB port.  
There doesn't
seem to be a way for software to know this either.  In the end I think the only 
way to manage
this is to start as conservatively as possible in all cases and then let the 
user configure what
is appropriate for the particular board and configuration.

There is also the fact that not all use cases are the same.  I am thinking of 
implementing
a couple of boot options to allow the CPU frequency to be set to a user 
specified value
very early in the boot process and to disallow any subsequent changes to the 
value.  The
reason I want this is that I want to use the CPU cycle counter as a system 
clock source,
but only if there is no possible way for its frequency to change once the clock 
is configured,
so I'd like the one boot option to set the frequency appropriately and the 
other to indicate
that configuring a time counter based on the cycle counter won't end up causing 
misery.
This is a good way to use this particular board since the SoC also includes 
hardware
timestamp capture peripherals which can maybe capture the PPS timing output of a
GPS receiver with +/- 5 ns precision, plus IEEE 1588 hardware support to use to 
calibrate
the Ethernet, and that plus the precise system clock source is the raw material 
needed to
build the very most accurate NTP server that $80 can buy.

It wouldn't be good to do too much frequency fiddling automatically since that 
would screw
applications which need the frequency to be a constant.

Dennis Ferguson