Re: Regarding Devfreq

Re: Regarding Devfreq

[함명주]

[-- Attachment #1.1: Type: text/html, Size: 6912 bytes --]

[-- Attachment #1.2: 201203211919047_QKNMBDIF.jpg --]
[-- Type: image/jpeg, Size: 72722 bytes --]

[-- Attachment #1.3: 201203211919122_7EUABGFC.jpg --]
[-- Type: image/jpeg, Size: 72722 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Regarding Devfreq

[Satendra...]

[-- Attachment #1.1.1: Type: text/plain, Size: 4594 bytes --]

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


On 21 March 2012 15:49, 함명주 <myungjoo.ham@samsung.com> 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@gmail.com>
>
> *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@samsung.com> 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@gmail.com>
>>
>> *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@gmail.com> 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
>
>
>
>

[-- Attachment #1.1.2: Type: text/html, Size: 7365 bytes --]

[-- Attachment #1.2: 201203211919122_7EUABGFC.jpg --]
[-- Type: image/jpeg, Size: 72722 bytes --]

[-- Attachment #1.3: 201203211919047_QKNMBDIF.jpg --]
[-- Type: image/jpeg, Size: 72722 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Regarding Devfreq

[MyungJoo Ham]

2012/3/28 Satendra... <satendra.pratap@gmail.com>
>
> 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@samsung.com> 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@gmail.com>
>>
>> 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@samsung.com> 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@gmail.com>
>>>
>>> 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@gmail.com> 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@lists.linux-foundation.org
> 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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: Regarding Devfreq

[Satendra...]

[-- Attachment #1.1: Type: text/plain, Size: 9171 bytes --]

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:

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@gmail.com> wrote:

> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
> >
> > 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@samsung.com> 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@gmail.com>
> >>
> >> 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@samsung.com> 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@gmail.com>
> >>>
> >>> 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@gmail.com> 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@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>
>
>
>
> --
> MyungJoo Ham, Ph.D.
> System S/W Lab, S/W Center, Samsung Electronics
>

[-- Attachment #1.2: Type: text/html, Size: 13272 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Regarding Devfreq

[MyungJoo Ham]

On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@gmail.com> 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.

>
> 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@gmail.com> wrote:
>>
>> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
>> >
>> > 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@samsung.com> 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@gmail.com>
>> >>
>> >> 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@samsung.com> 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@gmail.com>
>> >>>
>> >>> 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@gmail.com> 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@lists.linux-foundation.org
>> > 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
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: Regarding Devfreq

[MyungJoo Ham]

On Mon, Apr 16, 2012 at 7:19 PM, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
> On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@gmail.com> 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@gmail.com> wrote:
>>>
>>> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
>>> >
>>> > 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@samsung.com> 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@gmail.com>
>>> >>
>>> >> 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@samsung.com> 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@gmail.com>
>>> >>>
>>> >>> 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@gmail.com> 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@lists.linux-foundation.org
>>> > 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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: Regarding Devfreq

[Satendra...]

[-- Attachment #1.1: Type: text/plain, Size: 15066 bytes --]

Hi Ham,

On 16 April 2012 17:40, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:

> On Mon, Apr 16, 2012 at 7:19 PM, MyungJoo Ham <myungjoo.ham@gmail.com>
> wrote:
> > On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@gmail.com>
> 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.
>
>
Yes thats true that we will have multiple instances of function calls but
every instance of driver
will have its own copy of counters which can be accessed through platform
data.
So AFAICS we need not to worry about concurrency issue because no instance
will touch the
counters of another instance. Please correct if i am wrong.

Below is the code using ktime API:

typedef struct devfreq_perf_counters {
#ifdef DEVFREQ_USE_KTIME
        ktime_t fentry_time; /* jiffies at the enrty of a func */
        ktime_t start_time; /* starting jiffies for every busy/total \
                             load cal in the last x seconds*/
        ktime_t prev_count; /* last jiffies count */
        s64 busy_time; /* total execution jiffies count in the last \
                              x seconds */
#else
        unsigned long fentry_time; /* jiffies at the enrty of a func */
        unsigned long start_time; /* starting jiffies for every busy/total \
                                             load cal in the last x
seconds*/
        unsigned long prev_count; /* last jiffies count */
        unsigned long busy_time; /* total execution jiffies count in the
last \
                                      x seconds */
#endif
}devfreq_counters;

#ifdef DEVFREQ_USE_KTIME
/* using ktime */
        #define devfreq_func_start(dc) do {\
                (dc)->fentry_time = ktime_get();\
        }while(0)

        #define devfreq_func_end(dc) do {\
                (dc)->prev_count = ktime_get();\
                (dc)->busy_time += ktime_to_ns(ktime_sub((dc)->prev_count, \
                                        (dc)->fentry_time));\
        }while(0)

        #define module_busy_time(dc)    ((dc)->busy_time)

        #define module_busy_plus_not_busy_time(dc) \
                ktime_to_ns(ktime_sub(ktime_get(), (dc)->start_time))

        #define devfreq_reset_counters(dc) do { \
                (dc)->start_time = ktime_get();\
        }while(0)
#else
        #define devfreq_func_start(dc) \
                (dc)->fentry_time = jiffies

        #define devfreq_fun_end(dc) do { \
                (dc)->prev_count = (jiffies)-((dc)->fentry_time);\
                (dc)->busy_time += (dc)->prev_count;\
        }while(0)

        #define module_busy_time(dc) \
                jiffies_to_usecs((dc)->busy_time)

        #define module_busy_plus_not_busy_time(dc) \
                jiffies_to_usecs(((jiffies) - (dc)->start_time))

        #define devfreq_reset_counters(dc) do { \
                (dc)->fentry_time = 0UL; \
                (dc)->prev_count = 0UL; \
                (dc)->busy_time = 0UL; \
                (dc)->start_time = jiffies;\
        }while(0)
#endif

Thanks,
Satendra


> >>
> >> 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@gmail.com> wrote:
> >>>
> >>> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
> >>> >
> >>> > 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@samsung.com> 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@gmail.com>
> >>> >>
> >>> >> 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@samsung.com> 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@gmail.com>
> >>> >>>
> >>> >>> 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@gmail.com>
> 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@lists.linux-foundation.org
> >>> > 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
>

[-- Attachment #1.2: Type: text/html, Size: 22473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Regarding Devfreq

[MyungJoo Ham]

2012/4/17 Satendra... <satendra.pratap@gmail.com>:
> Hi Ham,
>
> On 16 April 2012 17:40, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>>
>> On Mon, Apr 16, 2012 at 7:19 PM, MyungJoo Ham <myungjoo.ham@gmail.com>
>> wrote:
>> > On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@gmail.com>
>> > 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.
>>
>
> Yes thats true that we will have multiple instances of function calls but
> every instance of driver
> will have its own copy of counters which can be accessed through platform
> data.

Even if each instance of driver has its own data structure, there
could be concurrent function calls to one driver, which will cause
problems.

I'm not talking about:
Thread 1: do_something_on(dev A)
Thread 2: do_something_on(dev B)
I'm talking about:
Thread 1: do_something_on(dev A)
Thread 2: do_something_on(dev A)


> So AFAICS we need not to worry about concurrency issue because no instance
> will touch the
> counters of another instance. Please correct if i am wrong.
>
> Below is the code using ktime API:
>
> typedef struct devfreq_perf_counters {
> #ifdef DEVFREQ_USE_KTIME
>         ktime_t fentry_time; /* jiffies at the enrty of a func */
>         ktime_t start_time; /* starting jiffies for every busy/total \
>                              load cal in the last x seconds*/
>         ktime_t prev_count; /* last jiffies count */
>         s64 busy_time; /* total execution jiffies count in the last \
>                               x seconds */
> #else
>         unsigned long fentry_time; /* jiffies at the enrty of a func */
>         unsigned long start_time; /* starting jiffies for every busy/total \
>                                              load cal in the last x
> seconds*/
>         unsigned long prev_count; /* last jiffies count */
>         unsigned long busy_time; /* total execution jiffies count in the
> last \
>                                       x seconds */
> #endif
> }devfreq_counters;
>
> #ifdef DEVFREQ_USE_KTIME
> /* using ktime */
>         #define devfreq_func_start(dc) do {\
>                 (dc)->fentry_time = ktime_get();\
>         }while(0)
>
>         #define devfreq_func_end(dc) do {\
>                 (dc)->prev_count = ktime_get();\
>                 (dc)->busy_time += ktime_to_ns(ktime_sub((dc)->prev_count, \
>                                         (dc)->fentry_time));\
>         }while(0)
>
>         #define module_busy_time(dc)    ((dc)->busy_time)
>
>         #define module_busy_plus_not_busy_time(dc) \
>                 ktime_to_ns(ktime_sub(ktime_get(), (dc)->start_time))
>
>         #define devfreq_reset_counters(dc) do { \
>                 (dc)->start_time = ktime_get();\
>         }while(0)
> #else
>         #define devfreq_func_start(dc) \
>                 (dc)->fentry_time = jiffies
>
>         #define devfreq_fun_end(dc) do { \
>                 (dc)->prev_count = (jiffies)-((dc)->fentry_time);\
>                 (dc)->busy_time += (dc)->prev_count;\
>         }while(0)
>
>         #define module_busy_time(dc) \
>                 jiffies_to_usecs((dc)->busy_time)
>
>         #define module_busy_plus_not_busy_time(dc) \
>                 jiffies_to_usecs(((jiffies) - (dc)->start_time))
>
>         #define devfreq_reset_counters(dc) do { \
>                 (dc)->fentry_time = 0UL; \
>                 (dc)->prev_count = 0UL; \
>                 (dc)->busy_time = 0UL; \
>                 (dc)->start_time = jiffies;\
>         }while(0)
> #endif
>
> Thanks,
> Satendra
>
>>
>> >>
>> >> 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@gmail.com> wrote:
>> >>>
>> >>> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
>> >>> >
>> >>> > 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@samsung.com> 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@gmail.com>
>> >>> >>
>> >>> >> 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@samsung.com> 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@gmail.com>
>> >>> >>>
>> >>> >>> 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@gmail.com>
>> >>> >>> 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@lists.linux-foundation.org
>> >>> > 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
>
>



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