> On 23 August 2012 09:57, MyungJoo Ham <myungjoo.ham(a)samsung.com> wrote:
> >> > On 20 August 2012 12:50, 함명주 <myungjoo.ham(a)samsung.com> wrote:
> >> >
> >> > > Prepare devfreq core framework to support devices which
> >> > > can idle. When device idleness is detected perhaps through
> >> > > runtime-pm, need some mechanism to suspend devfreq load
> >> > > monitoring and resume when device is back online. Present
> >> > > code continues monitoring unless device is removed from
> >> > > devfreq core.
> >> > >
> >> > > This patch introduces following updates,
> >> > >
> >> > > - move device load monitoring logic to ondemand governor as
> >> > > it is specific to ondemand.
> >> >
> >> >
> >> > We have this ondemand governor in the mainline devfreq. However,
> >> > we have (not upstreamed yet) governors with specific purpose (for
> >> > GPU or for a specific chip) with load monitoring logic. Although
> >> > we don't have them upstreamed yet, why don't you keep the monitoring
> >> > logic sharable by other governors. (From today, I'm not objecting to
> >> > have individual workqueue, but I still don't want to let each active
> >> > governor reimplement the same things.)
> >> >
> >> >
> >>
> >> If more governors are planned based on load monitoring, possibly
> >> ondemand is not good enough even after adding additional
> >> configurable parameters. Could you please describe one such
> >> case which demand new governor?
> >>
> >> Please find my next comments.
> >
> > GPU devfreq driver requires behaviors similar to conservative though
> > not exactly same.
> >
> > In our internal development branch, it increases frequencies differently
> > according to the current usage (# GPU cores used and % each core activated).
> > If it's almost 100% and the queue is filling up, it goes to max.
> > If it's (for example) 98%, it goes to the next faster step.
> > Besides, GPU developers want to differ the poling intervals according
> > to the current frequency.
> >
> >
> > Another case is with bus + memory-interface case. We are going to use
> > a custom governor for them as each bus and memory-interface has its
> > own DVFS capability while we want them to coordinate. The two drivers
> > may be hooked by the custom governor. We don't have a specific detail
> > with this as it is developed by another division. However, what I know
> > is that they are going to use their own custon governor with
> > ondemand-like behavior in principle.
> >
> Ok. Thanks.
> >
> > Because devfreq is meant to be used by various types of devices,
> > we cannot assume that the default governor is "mostly" fine.
> > Device driver writers can embed governors in their own devfreq
> > driver code ("custom governor").
> >
> >
> >> >
> >> >
> >> >
> >> > > - devfreq core interacts with governors via events to perform
> >> > > specific actions. These events include start/stop devfreq,
> >> > > and frequency limit changes outside devfreq. This sets ground
> >> > > for adding suspend/resume events.
> >> >
> >> >
> >> > event_handler with START/STOP/UPDATE seem fine.
> >> >
> >> > However, init() and exit() should be different from START/STOP.
> >> > We do not need to do init and exit every time when we do runtime
> >> > suspend/resume.
> >> >
> >> >
> >>
> >> I agree and its already taken care in this patch.
> >>
> >> DEVFREQ_GOV_START : Event for initializing and starting of devfreq governor
> >> for a device. Happens only when device is added using devfreq_add_device().
> >>
> >> DEVFREQ_GOV_STOP: Event for stopping and uninitialization of devfreq governor
> >> for a device. Happens only when device is removed using devfreq_remove_device().
> >>
> >> Events introduced in next patch (2/3) -
> >> DEVFREQ_GOV_SUSPEND: Event for suspending devfreq of a device. I.e
> >> suspending of load monitoring of device in case of ondemand governor.
> >> Happens only when devfreq_suspend_device() is called.
> >>
> >> DEVFREQ_GOV_RESUME: Event for resuming devfreq of a device. I.e
> >> continue load monitoring of already suspended device in case of ondemand
> >> governor. Happens only when devfreq_resume_device() is called.
> >
> > Ah.. suspend/resume events are seperated. Please never mind this.
> >
> >> >
> >> > > - use per device work instead of global work to monitor device
> >> > > load. This enables suspend/resume of device devfreq and
> >> > > reduces monitoring code complexity.
> >> >
> >> >
> >> > It's fine to have a delayed work struct per device.
> >> >
> >> > However, please try to keep as many things/features in devfreq.c as
> >> > possible; i.e., reduce features and code size of governors. Because,
> >> > we will be supporting various types of devices with devfreq, there
> >> > will be various governors and I don't want them to have shared things
> >> > reimplemented. Dealing with the delayed work at devfreq.c and let
> >> > governors choose to use it (at its struct) or not should be fine.
> >> >
> >> >
> >>
> >> Delayed work is of only relevance to ondemand governor - justifies why
> >> struct delayed work moved from devfreq.c to governor_simpleondemand.c.
> >> When delayed work is optional for governors to use, then let governors
> >> handle them if needed instead of devfreq core.
> >>
> >> With this change, we will not be forcing next upcoming devfreq governors
> >> to use delayed work for load monitoring(if required) but instead flexibility
> >> to have their own mechanisms. Its up to the governors to decide
> >> how it wants to do dvfs of a device. But imperative to respond the events.
> >
> > As mentioned above, please do not assume that the default governors
> > (drivers/devfreq/governor_*.c) will be only governors available and
> > ondemand will be the only "active" governor for the future.
> >
> > I think it'd be better for the driver writes to reuse code than to
> > copy and paste the code.
> >
> > Some governors may use some other polling/sampling mechanisms; however,
> > still, providing delayed work at the core does not mean that governors
> > must use the default delayed work struct. They may simply not use it
> > as userspace, performance, and powersave do.
> >
>
> If code re-use is only the concern, instead of core handling delayed work
> which is optional for governors, how about providing load monitoring
> helper functions to governors? something like,
>
> drivers/devfreq/governor.h
> ------------------------------------
> int devfreq_monitor_start(struct devfreq *devfreq);
> int devfreq_monitor_stop(struct devfreq *devfreq);
> int devfreq_monitor_suspend(struct devfreq *devfreq);
> int devfreq_monitor_resume(struct devfreq *devfreq);
Yes, putting a delayed-work struct in struct devfreq and let devfreq.c
handle that delayed-work is what I think appropriate, too.
Anyway, what would be the difference between start vs resume and between
stop vs suspend for the per-devfreq-struct delayed-work at the side of
devfreq.c? Devfreq.c will simply start/stop the delayed-work with the
values in devfreq, won't it? Or would there be any common tasks for suspend
and resume that are not going to be required for start/stop?
Assuming that start/stop will also be used by userspace input of
"polling = some number / 0", it appears that there would be no
difference with suspend/resume.
>
> These delayed work handling functions will be implemented by devfreq.c
> and are called from governors in response to events.
>
> With this, governors can re-use the delayed work based load monitoring
> mechanism and also have flexibility to implement their own monitoring
> mechanism based on their objectives.
>
> >>
> >> >
> >> > In this patchset, the size of ondemand governor has been enlarged
> >> > too much for that purpose.
> >
> > I said this because I do not want governors to act as if they are core
> > and I do not want to make writing governors too difficult for device
> > driver writers. I want them to focus on the "policy" only, not the
> > mechanism.
> >
> >> >
> >> >
> >> > > - Force devfreq users to set min/max supported frequencies in
> >> > > device profile to help governors to predict target frequecy
> >> > > with in limits.
> >> >
> >> >
> >> > Is this really necessary?
> >> >
> >> >
> >> Yes. Mainly for two reasons,
> >>
> >> 1. Devfreq core provides sysfs interface for usespace to set min/max
> >> operating frequency for a device. These values must be within device
> >> supported min/max frequency limits.
> >
> > No. they do not need to be within device supported limits.
> >
> > When I say "CPU should be running at least 50MHz" when the CPU supports
> > 1000MHz ~ 3000MHz, there is no problem. Running at 1000MHz does not
> > contradict with the condition.
> >
> > When I say "CPU should be running at least 4000MHz" for the same CPU,
> > It is fine to set the CPU at max available.
> >
> >> 2. Governors should know device supported min/max opps and use
> >> them where ever needed. Never assume UINT_MAX as max frequency.
> >
> > The core and governors do not need to know such information.
> > They only need to provide "recommended" frequency. The corresponding
> > driver is going to interpret it properly. Whenever we can,
> > it's better to remove device specific information from governors
> > and cores as long as it does not significantly increase the
> > complexity of drivers.
> >
>
> Sorry, but I disagree on this point. Devfreq core should not consider user
> input for granted and suggest next recommended target freq which is beyond
> device supported frequency and let driver to interpret it. I don't think passing
> device supported min/max from driver would increase the complexity of driver.
> Rather it would help in recommending freq with in limits.
>
> This information also helps user space to know the device operating limits.
With the optional frequency statistics support proposed by Jonghwa Lee,
devfreq.c is going to be accepting the list of operable frequencies,
where the max/min values are trivially extracted.
With this optional values, we can create sysfs entries to show max/min
possible or operable frequencies. (they are difference from the
min_freq and max_freq, which are user's limits)
I still don't understand why enforcing devfreq device drivers to
declare min/max frequencies to devfreq core. Because the devfreq
device drivers already know the hardware limits (otherwise, we
are not able to enforce them to do so), it is not beneficial for
the device driver to let devfreq core provide such limits to
the device drivers (they already know).
Yes, passing values filtered by min/max values reported by device drivers
from core does not increase the complexity at device drivers. However, it
adds codes at _every_ governor to filter the values, which is going to
be filtered at each device driver anyway. For devices supporting 100, 200,
400 MHz, governors will pass 150, 151, 201, 203, and such even if we
filter min/max.
I just don't see a benefic to enforce device drivers to declare
min/max to the core and enforce governors to recommend between the
restricted values, which are going to be regulated at device drivers
anyway. (and very trivial to be regulated by drivers)
If this is meant to show the min/max values to the users, making it optional
should be enough.
Besides, allowing users to enter any arbitrary large values (e.g., 9999999999)
to make it run at maximum frequency and enter any small values (e.g., 1) to
make it run at minimum frequency makes things easier. I don't see why
we should get them errors for such inputs.
Cheers!
MyungJoo
>
> > UINT_MAX means "I recommend to run as fast as possible." Then, the
> > driver only needs to provide the fastest frequency. The core and
> > governor does not need to say the specific frequency.
> >
> >
> > Cheers!
> > MyungJoo
> >
> >
> >>
> >>
> >>
> >> >
> >> > The devfreq apis are not modified and are kept intact.
> >>
> >>
> >> The ABIs are not.
> >>
> >> You can no longer do "# echo 0 > ABI_path" in order to deactivate.
> >>
> >>
> >> Only relevant for ondemand governor. Load monitoring can be
> >> deactivated when polling_ms is set to zero. Next version of patch
> >> will fix this. Thanks.
> >>
> >>
> >>
> >> Cheers!
> >> MyungJoo
> >>
> >>
> >> >
> >> > Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org>
> >> > ---
> >>
> >>
> >> ps. please make the patch a bit more readable. (please don't shuffle
> >> the location of pre-existed functions)
> >>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Rajagopal
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> MyungJoo Ham (함명주), PHD
> >>
> >> System S/W Lab, S/W Platform Team, Software Center
> >> Samsung Electronics
> >> Cell: +82-10-6714-2858
> >>
> >>
> >>
> >>
> >>
>
>
>
> --
> Regards,
> Rajagopal
>
>
>
>
>
>
>
On 08/30/2012 01:26 PM, Rajendra Nayak wrote:
> I tried 2012.07 (http://releases.linaro.org/12.07) ubuntu images and I get this
> when I run perf :(
>
> perf_3.4.0-2: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
If your board connected to the Internet, or if you're able to access package
repositories in another way, try:
apt-get install libelf1 libdw1 liblzma5 binutils libbz2-1.0 zlib1g
> Do you always have display connected on your panda while using ubuntu? Mine without display keeps
> throwing these error logs
Yes, a lot of them on the console; due to this, I run almost everything via ssh session.
Dmitry
Hi all,
In the next hour or so we'll be deploying new code to
snapshots.linaro.org (the web site itself): this means full BUILD-INFO
support for those that care.
Since the release is right around the corner, we are ready to roll back
as soon as someone notices a problem.
FWIW, we'll still be running the old code on oldsnapshots.linaro.org
(for OpenID/SSL access, you will get a "wrong certificate" warning
giving you a certificate for snapshots.linaro.org).
Cheers,
Danilo
FYI
---------- Forwarded message ----------
From: Jean-Baptiste Queru <jbq(a)android.com>
Date: 28 August 2012 15:59
Subject: Contributions and conflict-prone areas
To: android-contrib(a)googlegroups.com
I've been looking at many Android contributions recently, which gives
be some good visibility over the difficulties in merging changes all
the way upstream into Google's internal tree.
Generally speaking, at the moment the gap between AOSP and Google's
internal master tree is unusually small, and that allows a very large
majority of contributions to merge without conflicts.
By looking at many changes, I spotted 3 areas where merges don't go
smoothly. Those areas are Bluetooth, Email, and Location, and most
changes related to those cause merge problems. Digging a bit, those
look like they've been refactored quite heavily in Google's internal
tree, which causes the conflicts. For anyone considering to contribute
in any of those 3 areas. I recommend waiting until the next major
release (and I don't have any ETA for it).
>From what I've seen, merges are uneventful in all other areas of the
Android tree.
Thanks,
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
--
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
On 08/28/2012 10:58 AM, Rajendra Nayak wrote:
> Does perf work fine on panda with the Linaro Ubuntu images?
Yes,it should work for 2012.07 Ubuntu images (except cross-replaying,
which works since 3.6.0-rc1).
> Wanted to experiment with the tool a little, was wondering whats a good place to
> start.
You can start from my rudimentary page at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/PerfRecordReplay
As it's name says, it's mostly around recording and replaying features.
Common information, examples and so may be found at:
https://perf.wiki.kernel.org/index.php/Main_Page
Dmitry
https://wiki.linaro.org/projects/big.LITTLE.MP
Announcement:
=============
It is regretful that Paul Larson will be returning to Canonical after
this week. I want to personally thank Paul for the huge effort and
creativity that he has given to the big.LITTLE projects. Each project
would have been poorer without his input. Naresh will continue to be a
great asset to the team on QA and Alexander Sack will be filling in
for Paul as the search continues for a QA team lead.
Roadmap Cards
=============
http://cards.linaro.org/browse/CARD-34 and
http://cards.linaro.org/browse/CARD-35 are being closed out and
planning has just begun for the next series of Linaro roadmap cards
for big.LITTLE MP. Stay tuned for links.
Blueprints
=========
https://blueprints.launchpad.net/linaro-power-kernel/+spec/perf-record-repl…
- Done as of 3.6-rc1 but not integrated into Linaro LEBs yet.
https://blueprints.launchpad.net/linaro-power-kernel/+spec/big.little.mp-ho…
- In progress, target for 12.09 cycle
https://blueprints.launchpad.net/linaro-power-kernel/+spec/cpuidle-add-cpu-…
- In progress, target for 12.09 cycle
https://blueprints.launchpad.net/linaro-power-kernel/+spec/cpuidle-upstream…
Work to be completed this cycle, unfinished items may be included in a
new blueprint.
https://blueprints.launchpad.net/linaro-qa/+spec/sched-test-porting-to-andr…
- in progress
Miscellaneous items
=================
Main changes for V7 of MP pull
- Based on v3.6-rc3
- per-task-load-average updated with v3
- applied Tixy's patch from fast-slow-cpu-dt-v1 to
task-placement-v1 as they are
somewhat related only. And so removed fast-slow-cpu-dt-v1 branch
We've received some feedback from out big.LITTLE TC2 build:
· The image boots fine.
· Successfully ran: Sunspider, V8, 0xbench 2D and 3D tests
· Problems: Random crashes during BBench and web-browsing.
a) Downloaded the pre-built image from link given by Linaro (OK)
b) Copying the image on the SD card (OK)
c) Copying SD card contents to NOR flash (Issues, finally OK)
- copy boot/v2p-ca15-tc2.dtb
/media/VEMSD/SOFTWARE/TC2/tc2_dtb.bin should be corrected by Linaro as
cp /media/boot/v2p-ca15-tc2.dtb /media/VEMSD/SOFTWARE/TC2/tc2_dtb.bin
- People familiar with it may not have a problem, but
novices like me to the setup follows the instruction by letter!
- I made a silly mistake also at this stage where i
misspelled the extension, and later when i tried to boot the board in
the POST step it failed unable to locate the device tree description
file.
- Before ejecting the cards issued a ‘sync’ command
(following advice from others).
d) Boot the board (Issues, finally OK)
- Discovered a further mistake made in the images.txt edit
and bootscr.txt which caused the flashing and booting up of image to
fail respectively.
- Corrected both these typo issues and now i have got
android booted up.
Summary:
With the pre-built image option and instructions
provided user was able to flash the device successfully and see the
android boot up screen. Only small issue is the above copy instruction
mentioned in step c) in Linaro web page slightly incomplete, otherwise
their instructions were good.
The project plan is at
https://docs.google.com/a/linaro.org/document/d/1XI9FaEd6dYfCEDezboF7gWtrTO…
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
> On 20 August 2012 15:15, 함명주 <myungjoo.ham(a)samsung.com> wrote:
> >> Devfreq returns governor predicted frequency as current
> >> frequency via sysfs interface. But device may not support
> >> all frequencies that governor predicts. As per the design
> >> its driver responsibility to maintain current frequency
> >> at which device is operating. So add a callback in device
> >> profile to fix this.
> >>
> >> Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org>
> >
> > We still need to support "intended frequency".
> >
> > The "cur_freq" node is to show the intended frequency.
> > As told before, you need to make additional API and ABI for the
> > "actual frequency".
> >
> I don't think userspace will be interested in "intended frequency", i.e
> governor predicted next target frequency unless code is being
> debugged. More over device may not support all opps that
> governor predicts. Hence cur_freq node is fixed to show freq
> at the which device is operating.
>
> Let me know if you still think, intended frequency should be
> exposed to userspace.
Like CPUfreq, (scaling_cur_freq vs cpuinfo_cur_freq) device driver
developers are often very interested in such values. At least for me,
such information has been very helpful for production kernels.
Cheers!
MyungJoo
>
> >
> > Cheers!
> > MyungJoo
> >
> >> ---
> >> drivers/devfreq/devfreq.c | 14 ++++++++++++--
> >> include/linux/devfreq.h | 6 +++---
> >> 2 files changed, 15 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> >> index 375b5aa1..798e8ca 100644
> >> --- a/drivers/devfreq/devfreq.c
> >> +++ b/drivers/devfreq/devfreq.c
> >> @@ -176,7 +176,6 @@ struct devfreq *devfreq_add_device(struct device *dev,
> >> devfreq->dev.release = devfreq_dev_release;
> >> devfreq->profile = profile;
> >> devfreq->governor = governor;
> >> - devfreq->previous_freq = profile->initial_freq;
> >> devfreq->governor_data = data;
> >> devfreq->nb.notifier_call = devfreq_notifier_call;
> >> devfreq->min_freq = profile->min_freq;
> >> @@ -272,7 +271,18 @@ static ssize_t show_governor(struct device *dev,
> >> static ssize_t show_freq(struct device *dev,
> >> struct device_attribute *attr, char *buf)
> >> {
> >> - return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
> >> + int ret;
> >> + unsigned long freq;
> >> + struct devfreq *devfreq = to_devfreq(dev);
> >> +
> >> + if (devfreq->profile->get_cur_freq) {
> >> + ret = devfreq->profile->get_cur_freq(devfreq->dev.parent,
> >> + &freq);
> >> + if (!ret)
> >> + return sprintf(buf, "%lu\n", freq);
> >> + }
> >> +
> >> + return sprintf(buf, "<unknown>");
> >> }
> >>
> >> static ssize_t store_min_freq(struct device *dev, struct device_attribute *attr,
> >> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> >> index 7c6517f..43f111f 100644
> >> --- a/include/linux/devfreq.h
> >> +++ b/include/linux/devfreq.h
> >> @@ -76,6 +76,8 @@ struct devfreq_dev_status {
> >> * explained above with "DEVFREQ_FLAG_*" macros.
> >> * @get_dev_status The device should provide the current performance
> >> * status to devfreq, which is used by governors.
> >> + * @get_cur_freq The device should provide the current frequency
> >> + * at which it is operating.
> >> * @exit An optional callback that is called when devfreq
> >> * is removing the devfreq object due to error or
> >> * from devfreq_remove_device() call. If the user
> >> @@ -91,6 +93,7 @@ struct devfreq_dev_profile {
> >> int (*target)(struct device *dev, unsigned long *freq, u32 flags);
> >> int (*get_dev_status)(struct device *dev,
> >> struct devfreq_dev_status *stat);
> >> + int (*get_cur_freq)(struct device *dev, unsigned long *freq);
> >> void (*exit)(struct device *dev);
> >> };
> >>
> >> @@ -119,7 +122,6 @@ struct devfreq_governor {
> >> * @nb notifier block used to notify devfreq object that it should
> >> * reevaluate operable frequencies. Devfreq users may use
> >> * devfreq.nb to the corresponding register notifier call chain.
> >> - * @previous_freq previously configured frequency value.
> >> * @governor_data Private data of the governor. The devfreq framework
> >> * does not touch this.
> >> * @min_freq Limit minimum frequency requested by user (0: none)
> >> @@ -142,8 +144,6 @@ struct devfreq {
> >> const struct devfreq_governor *governor;
> >> struct notifier_block nb;
> >>
> >> - unsigned long previous_freq;
> >> -
> >> void *governor_data; /* private data for governors */
> >>
> >> unsigned long min_freq;
> >> --
> >> 1.7.11.3
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
> --
> Regards,
> Rajagopal
>
>
>
>
>
>
>
> > On 20 August 2012 12:50, 함명주 <myungjoo.ham(a)samsung.com> wrote:
> >
> > > Prepare devfreq core framework to support devices which
> > > can idle. When device idleness is detected perhaps through
> > > runtime-pm, need some mechanism to suspend devfreq load
> > > monitoring and resume when device is back online. Present
> > > code continues monitoring unless device is removed from
> > > devfreq core.
> > >
> > > This patch introduces following updates,
> > >
> > > - move device load monitoring logic to ondemand governor as
> > > it is specific to ondemand.
> >
> >
> > We have this ondemand governor in the mainline devfreq. However,
> > we have (not upstreamed yet) governors with specific purpose (for
> > GPU or for a specific chip) with load monitoring logic. Although
> > we don't have them upstreamed yet, why don't you keep the monitoring
> > logic sharable by other governors. (From today, I'm not objecting to
> > have individual workqueue, but I still don't want to let each active
> > governor reimplement the same things.)
> >
> >
>
> If more governors are planned based on load monitoring, possibly
> ondemand is not good enough even after adding additional
> configurable parameters. Could you please describe one such
> case which demand new governor?
>
> Please find my next comments.
GPU devfreq driver requires behaviors similar to conservative though
not exactly same.
In our internal development branch, it increases frequencies differently
according to the current usage (# GPU cores used and % each core activated).
If it's almost 100% and the queue is filling up, it goes to max.
If it's (for example) 98%, it goes to the next faster step.
Besides, GPU developers want to differ the poling intervals according
to the current frequency.
Another case is with bus + memory-interface case. We are going to use
a custom governor for them as each bus and memory-interface has its
own DVFS capability while we want them to coordinate. The two drivers
may be hooked by the custom governor. We don't have a specific detail
with this as it is developed by another division. However, what I know
is that they are going to use their own custon governor with
ondemand-like behavior in principle.
Because devfreq is meant to be used by various types of devices,
we cannot assume that the default governor is "mostly" fine.
Device driver writers can embed governors in their own devfreq
driver code ("custom governor").
> >
> >
> >
> > > - devfreq core interacts with governors via events to perform
> > > specific actions. These events include start/stop devfreq,
> > > and frequency limit changes outside devfreq. This sets ground
> > > for adding suspend/resume events.
> >
> >
> > event_handler with START/STOP/UPDATE seem fine.
> >
> > However, init() and exit() should be different from START/STOP.
> > We do not need to do init and exit every time when we do runtime
> > suspend/resume.
> >
> >
>
> I agree and its already taken care in this patch.
>
> DEVFREQ_GOV_START : Event for initializing and starting of devfreq governor
> for a device. Happens only when device is added using devfreq_add_device().
>
> DEVFREQ_GOV_STOP: Event for stopping and uninitialization of devfreq governor
> for a device. Happens only when device is removed using devfreq_remove_device().
>
> Events introduced in next patch (2/3) -
> DEVFREQ_GOV_SUSPEND: Event for suspending devfreq of a device. I.e
> suspending of load monitoring of device in case of ondemand governor.
> Happens only when devfreq_suspend_device() is called.
>
> DEVFREQ_GOV_RESUME: Event for resuming devfreq of a device. I.e
> continue load monitoring of already suspended device in case of ondemand
> governor. Happens only when devfreq_resume_device() is called.
Ah.. suspend/resume events are seperated. Please never mind this.
> >
> > > - use per device work instead of global work to monitor device
> > > load. This enables suspend/resume of device devfreq and
> > > reduces monitoring code complexity.
> >
> >
> > It's fine to have a delayed work struct per device.
> >
> > However, please try to keep as many things/features in devfreq.c as
> > possible; i.e., reduce features and code size of governors. Because,
> > we will be supporting various types of devices with devfreq, there
> > will be various governors and I don't want them to have shared things
> > reimplemented. Dealing with the delayed work at devfreq.c and let
> > governors choose to use it (at its struct) or not should be fine.
> >
> >
>
> Delayed work is of only relevance to ondemand governor - justifies why
> struct delayed work moved from devfreq.c to governor_simpleondemand.c.
> When delayed work is optional for governors to use, then let governors
> handle them if needed instead of devfreq core.
>
> With this change, we will not be forcing next upcoming devfreq governors
> to use delayed work for load monitoring(if required) but instead flexibility
> to have their own mechanisms. Its up to the governors to decide
> how it wants to do dvfs of a device. But imperative to respond the events.
As mentioned above, please do not assume that the default governors
(drivers/devfreq/governor_*.c) will be only governors available and
ondemand will be the only "active" governor for the future.
I think it'd be better for the driver writes to reuse code than to
copy and paste the code.
Some governors may use some other polling/sampling mechanisms; however,
still, providing delayed work at the core does not mean that governors
must use the default delayed work struct. They may simply not use it
as userspace, performance, and powersave do.
>
> >
> > In this patchset, the size of ondemand governor has been enlarged
> > too much for that purpose.
I said this because I do not want governors to act as if they are core
and I do not want to make writing governors too difficult for device
driver writers. I want them to focus on the "policy" only, not the
mechanism.
> >
> >
> > > - Force devfreq users to set min/max supported frequencies in
> > > device profile to help governors to predict target frequecy
> > > with in limits.
> >
> >
> > Is this really necessary?
> >
> >
> Yes. Mainly for two reasons,
>
> 1. Devfreq core provides sysfs interface for usespace to set min/max
> operating frequency for a device. These values must be within device
> supported min/max frequency limits.
No. they do not need to be within device supported limits.
When I say "CPU should be running at least 50MHz" when the CPU supports
1000MHz ~ 3000MHz, there is no problem. Running at 1000MHz does not
contradict with the condition.
When I say "CPU should be running at least 4000MHz" for the same CPU,
It is fine to set the CPU at max available.
> 2. Governors should know device supported min/max opps and use
> them where ever needed. Never assume UINT_MAX as max frequency.
The core and governors do not need to know such information.
They only need to provide "recommended" frequency. The corresponding
driver is going to interpret it properly. Whenever we can,
it's better to remove device specific information from governors
and cores as long as it does not significantly increase the
complexity of drivers.
UINT_MAX means "I recommend to run as fast as possible." Then, the
driver only needs to provide the fastest frequency. The core and
governor does not need to say the specific frequency.
Cheers!
MyungJoo
>
>
>
> >
> > The devfreq apis are not modified and are kept intact.
>
>
> The ABIs are not.
>
> You can no longer do "# echo 0 > ABI_path" in order to deactivate.
>
>
> Only relevant for ondemand governor. Load monitoring can be
> deactivated when polling_ms is set to zero. Next version of patch
> will fix this. Thanks.
>
>
>
> Cheers!
> MyungJoo
>
>
> >
> > Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org>
> > ---
>
>
> ps. please make the patch a bit more readable. (please don't shuffle
> the location of pre-existed functions)
>
>
>
>
> --
> Regards,
> Rajagopal
>
>
>
>
>
>
> --
>
> MyungJoo Ham (함명주), PHD
>
> System S/W Lab, S/W Platform Team, Software Center
> Samsung Electronics
> Cell: +82-10-6714-2858
>
>
>
>
>
Here is a summary of the updates from 2012.07.
Naming convention:
*linux-linaro-SOCNAM* use Andrey's linux-linaro branch
*linux-linaro-lt-SOCNAME* use a landing team branch
*linux-linaro-llt-SOCNAME* use Andrey's linux-linaro-tracking branch
(3.4 based)
3.5 jobs disabled because linux-linaro and lt's have moved to 3.6
package-and-publish-linux-linaro-vexpress-3.5
package-and-publish-linux-linaro-origen-3.5
package-and-publish-linux-linaro-lt-vexpress-3.5
3.4 llt jobs remaining because linux-linaro-tracking is still 3.4 based
package-and-publish-linux-linaro-llt-omap-3.4
package-and-publish-linux-linaro-llt-origen-3.4
package-and-publish-linux-linaro-llt-vexpress-3.4
3.x lt jobs remaining
package-and-publish-linux-linaro-lt-omap-3.4
tilt-3.4 branch is still active
package-and-publish-linux-linaro-lt-origen-3.5
branch is now ubuntu-tracking
package-and-publish-linux-linaro-lt-u8500-3.4
unsure of status
new 3.6 linux-linaro and lt jobs
package-and-publish-linux-linaro-vexpress-3.6
package-and-publish-linux-linaro-origen-3.6
package-and-publish-linux-linaro-lt-origen-3.6
based on tracking branch which is a work in progress and not yet stable
package-and-publish-linux-linaro-lt-vexpress-3.6
All jobs are in this view:
https://ci.linaro.org/jenkins/view/New%20Ubuntu%20Packaged%20Kernels/
Detailed info on repos, branches, configs and such are in each job's header.
--john