Re: Regarding Devfreq

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

 



2012/3/28 Satendra... <satendra.pratap@xxxxxxxxx>
>
> Hi Ham,
>
> In the below struct :
> struct devfreq_dev_status {
>         /* both since the last measure */
>         unsigned long total_time;
>         unsigned long busy_time;
>         unsigned long current_frequency;
>         void *private_data;
> };
>
> How to calculate total_time/busy_time? Does it require hardware support
> (may be some performance counters)?
>
> Thanks,
> Satendra

It is decided by each devfreq device driver, which is why
get_dev_status() is to be provided by the devfreq device driver.

If the device has performance counters, then, it's great, but
performance counters are not mandatory.

Here goes a list of mechanisms to fetch busy/total time:
- Performance counters
- Measure the time between "operation start" and "operation end" and
accumulate the time (getting busy time. probably by ktime?)
- Measure the idle time (CPUIDLE/CPUFREQ does this)
- Count the number of operation and calculate the operational time
based on the number.
- and so on.

As you can see in the list, you don't need a hardware support such as
performance counters.



Cheers!
MyungJoo.

>
>
> On 21 March 2012 15:49, 함명주 <myungjoo.ham@xxxxxxxxxxx> wrote:
>>
>> Hi Stendra,
>>
>>
>>
>> - Bascially, you can determine the voltage based on frequency; thus, we
>> do not need to determint voltages at DVFS framework. It is corresponding
>> device driver's responsibility even when we have AVS features. Thus, yes,
>> the target callback needs to control both frequency and voltage (and
>> anything else required to change the frequency/voltage)
>>
>>
>>
>> - I recommend to use regulator framework to control regulators unless you
>> really really need to ignore regulator framework. Don't reinvent the wheel.
>>
>>
>>
>> - The three steps you've mentioned are correct.
>>
>>
>>
>> - The mailing list is opened to all. You are welcomed to use it (CC'ed
>> linux-pm) and just CC needed people.
>>
>>
>>
>>
>>
>> Cheers!
>>
>> MyungJoo.
>>
>>
>>
>> ------- Original Message -------
>>
>> Sender : Satendra...<satendra.pratap@xxxxxxxxx>
>>
>> Date : 2012-03-21 19:03 (GMT+09:00)
>>
>> Title : Re: Re: Regarding Devfreq
>>
>>
>>
>> Hi Ham,
>>
>> Thank you very much for your reply. I will try not to disturb you much.
>> In Devfreq I dont see any API related to voltage scaling. Is it the
>> "->target" function's (in  struct devfreq_dev_profile)
>> responsibility to change the voltage as well with frequency?
>> Do we really need to register our regulators using regulator framework of
>> linux for voltage scaling?
>>
>> For a clear understanding I need to do following to use devfreq (I am
>> sorry as I may be verifying it again):
>> - define an instance of "struct devfreq_dev_profile" and provide
>> implementations of target, get_dev_status and exit callbacks
>> - Implement our choice of governer or use any one from already
>> implemented ones.
>> - call "devfreq_add_device" function from our driver's probe function.
>>
>> is that it? or do we need to do something else also?
>>
>> Thanks,
>> Satendra
>>
>>
>> On 21 March 2012 15:14, 함명주 <myungjoo.ham@xxxxxxxxxxx> wrote:
>>>
>>> Hello Satendra,
>>>
>>>
>>>
>>> - For Devfreq, OPP is optional though recommended for easier
>>> implementation. You can still implement all the needed things without OPP.
>>> OPP is just a simple data structure to store pairs of voltage and frequency.
>>>
>>>
>>>
>>> - Yes, you need to call devfreq_add_device() and supply the required
>>> data. You can implement your own governor or use one of predefined
>>> governors. Runtime replacement of governors like CPUfreq is "TODO" for now.
>>>
>>>
>>>
>>> - For example, you can see /drivers/devfreq/exynos4_bus.c. GPU, Display
>>> devfreq drivers are under development in other companies (ARM).
>>>
>>>
>>>
>>> Cheers!
>>>
>>> MyungJoo.
>>>
>>>
>>>
>>>
>>>
>>> ------- Original Message -------
>>>
>>> Sender : Satendra...<satendra.pratap@xxxxxxxxx>
>>>
>>> Date : 2012-03-21 17:31 (GMT+09:00)
>>>
>>> Title : Re: Regarding Devfreq
>>>
>>>
>>>
>>> Hi Ham,
>>>
>>> I have studied DVFS and what I feel is that we need to use OPP and
>>> Voltage regulator interfaces also to
>>> maintain Optimum Performance Points and to provide APIs to change the
>>> voltage.
>>> What I feel is that to use DVFS every driver has to
>>> call devfreq_add_device function to register that device to
>>> the devfreq framework. And in order to do that we have to
>>> implement devfreq_dev_profile and our choice of governer.
>>>
>>> I appreciate your help.
>>>
>>> Thanks,
>>> Satendra
>>>
>>> On 20 March 2012 12:16, Satendra... <satendra.pratap@xxxxxxxxx> wrote:
>>>>
>>>> Hi Ham,
>>>>
>>>> We are working on a new SoC for our new product and would want to use
>>>> your Devfreq
>>>> framework for our devices. Would you please let me know any other
>>>> implementation which
>>>> uses devfreq ? so that we could take that as a reference.
>>>> Or we would be the first one to start?
>>>>
>>>> Thanks,
>>>> Satendra
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> MyungJoo Ham (함명주), PHD
>>>
>>> System S/W Lab, S/W Platform Team, Software Center
>>> Samsung Electronics
>>> Cell: +82-10-6714-2858
>>>
>>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> MyungJoo Ham (함명주), PHD
>>
>> System S/W Lab, S/W Platform Team, Software Center
>> Samsung Electronics
>> Cell: +82-10-6714-2858
>>
>>
>
>
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm




--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux