On Mon, Apr 16, 2012 at 7:19 PM, MyungJoo Ham <myungjoo.ham@xxxxxxxxx> wrote:
> On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@xxxxxxxxx> wrote:
>> Hi Ham,
>>
>> I have used jiffies to calculate the busy time and total time for a module
>> (made of 'n' functions say).
>> I have added a bew structure:
>
> Hi.
>
> In my ARM SoC systems, one jiffy is 5ms. I don't think other systems
> won't vary too much (should be around several hundred us to several
> ms). Are you sure that jiffy has enough granularity for your system?
> If you are counting the length spent in a function call, shouldn't
> nsecs be usec? (ktime?). And for saving such values, the
> "private_data" is intended for individual devfreq drivers
> communicating with governors specific to the drivers. Devfreq->data is
> intended for individual devfreq governors. Thus, yes, platform-data is
> the right place for devfreq driver internal.
>
> Cheers!
> MyungJoo.
>
Ah.. and one missing point:
Please consider the concurrency. You may have multiple instance of
function calls in your device driver. And please do not block them by
simply adding locks there if this performance counting is the only
reason to make them mutually exclusive. This is another reason to
count nsecs (ktime) locally in the function and add the end-start
(local variable) into the aggregation variable (lock here only or use
atomic operators).
Cheers!
MyungJoo.
>>
>> typedef struct devfreq_perf_counters {
>> unsigned long func_entry_jiffies; /* jiffies at the enrty of a func
>> */
>> unsigned long start_jiffies; /* starting jiffies for every
>> busy/total \
>> load cal in the last x
>> seconds*/
>> unsigned long local_jiffies; /* last jiffies count */
>> unsigned long busy_jiffies; /* total execution jiffies count in the
>> last \
>> x seconds */
>> }devfreq_counters;
>>
>> This structure's instance can be included in the platform_data(or private
>> data) of the
>> driver which has to register itself with devfreq. This way while doing
>> set_drv_data, access
>> to these counters could be available all the time.
>>
>> Now there is one initialization function :
>>
>> void devfreq_counters_init(void *data)
>> {
>> devfreq_counters **dc = &data->dpc;
>>
>> *dc = kzalloc(sizeof (devfreq_counters), GFP_KERNEL);
>>
>> (*dc)->func_entry_jiffies = 0UL;
>> (*dc)->local_jiffies = 0UL;
>> (*dc)->busy_jiffies = 0UL;
>> (*dc)->start_jiffies = jiffies;
>>
>> return;
>> }
>>
>> This function initializes the counters and is called at the end of driver
>> initialiation function.
>>
>> Now there is a list of APIs as shown below:
>>
>> #define devfreq_jiffies_start(dc) \
>> dc->func_entry_jiffies = jiffies
>>
>> #define devfreq_jiffies_end(dc) do { \
>> dc->local_jiffies = (jiffies)-(dc->func_entry_jiffies);\
>> dc->busy_jiffies += dc->local_jiffies;\
>> }while(0)
>>
>> #define busy_jiffies_in_usec(dc) \
>> jiffies_to_usecs((dc)->busy_jiffies)
>>
>> #define busy_plus_not_busy_jiffies_in_usec(dc) \
>> jiffies_to_usecs(((jiffies) - (dc)->start_jiffies))
>>
>> #define devfreq_reset_counters(dc) do { \
>> dc->func_entry_jiffies = 0UL; \
>> dc->local_jiffies = 0UL; \
>> dc->busy_jiffies = 0UL; \
>> dc->start_jiffies = jiffies;\
>> }while(0)
>>
>> Description:
>> - devfreq_jiffies_start(dc): Will be called in the start of the function
>> (this is one of the functions
>> which we want to consider in measuring the busy time of the driver)
>> - devfreq_jiffies_end(dc): Will be called at the end of that function
>> - busy_jiffies_in_usec(dc): Will return jiffies for which all considered
>> (for busy time) driver's
>> functions were busy
>> - busy_plus_not_busy_jiffies_in_usec(dc): Total jiffies i.e. busy time + not
>> busy time of driver
>> - devfreq_reset_counters(dc): obvious
>>
>> I wanted the simple solution to busy and load and i thought about this. This
>> solution hasn't been verified
>> yet.
>>
>> Ham, can you please provide your views on it.
>>
>> Thanks,
>> Satendra
>>
>>
>> On 29 March 2012 07:44, MyungJoo Ham <myungjoo.ham@xxxxxxxxx> wrote:
>>>
>>> 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
>>
>>
>
>
>
> --
> MyungJoo Ham, Ph.D.
> System S/W Lab, S/W Center, Samsung Electronics
--
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
