linaro-dev August 2012

linaro-dev@lists.linaro.org

54 participants
64 discussions

Re: [PATCH 2/3][RFC] devfreq: Add suspend and resume apis

by MyungJoo Ham

> This patch adds suspend and resume apis needed > for devices which can idle. Suspend/resume apis > are called from driver to suspend/resume devfreq > load monitoring of that device. > > Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org> 1. Some devfreq devices may need their own code to do suspend/resume; e.g., setting a specific frequency for suspend (especially with suspend-to-RAM). 2. Are these new APIs (devfreq_suspend/resume_device()) intended to be used by runtime_pm and pm(Suspend-to-RAM) callbacks of the parent devices? If so, could you consider use the structure of runtime-pm (I don't have an idea on how to do this for now)? For example, when a device is being suspended, devfreq device's suspend is also called without calling it explicitly at the device driver's suspend callback. 3. As in the patch 1/3, could you consider to integrate class-wide features in devfreq.c, not in a governor? Cheers! MyungJoo > --- > drivers/devfreq/devfreq.c | 30 ++++++++++++++++++++++++++++++ > drivers/devfreq/governor_simpleondemand.c | 15 +++++++++++++++ > include/linux/devfreq.h | 16 ++++++++++++++++ > 3 files changed, 61 insertions(+) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 5aa23a8..375b5aa1 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -233,6 +233,36 @@ int devfreq_remove_device(struct devfreq *devfreq) > } > EXPORT_SYMBOL(devfreq_remove_device); > > +/** > + * devfreq_suspend_device() - Suspend devfreq of a device. > + * @devfreq the devfreq instance to be suspended > + */ > +int devfreq_suspend_device(struct devfreq *devfreq) > +{ > + if (!devfreq) > + return -EINVAL; > + > + devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_SUSPEND); > + > + return 0; > +} > +EXPORT_SYMBOL(devfreq_suspend_device); > + > +/** > + * devfreq_resume_device() - Resume devfreq of a device. > + * @devfreq the devfreq instance to be resumed > + */ > +int devfreq_resume_device(struct devfreq *devfreq) > +{ > + if (!devfreq) > + return -EINVAL; > + > + devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_RESUME); > + > + return 0; > +} > +EXPORT_SYMBOL(devfreq_resume_device); > + > static ssize_t show_governor(struct device *dev, > struct device_attribute *attr, char *buf) > { > diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c > index 7c70c30..95e4db9 100644 > --- a/drivers/devfreq/governor_simpleondemand.c > +++ b/drivers/devfreq/governor_simpleondemand.c > @@ -221,6 +221,21 @@ static int devfreq_simple_ondemand_func(struct devfreq *df, > ondemand_exit(df); > break; > > + case DEVFREQ_GOV_SUSPEND: > + if (delayed_work_pending(&data->work)) { > + data->stop_queuing = true; > + cancel_delayed_work_sync(&data->work); > + } > + break; > + > + case DEVFREQ_GOV_RESUME: > + if (!delayed_work_pending(&data->work)) { > + data->stop_queuing = false; > + queue_delayed_work(devfreq_wq, &data->work, > + msecs_to_jiffies(df->profile->polling_ms)); > + } > + break; > + > case DEVFREQ_GOV_LIMITS: > if (delayed_work_pending(&data->work)) { > mutex_lock(&df->lock); > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h > index 600cc2e..7c6517f 100644 > --- a/include/linux/devfreq.h > +++ b/include/linux/devfreq.h > @@ -56,6 +56,8 @@ struct devfreq_dev_status { > #define DEVFREQ_GOV_START 0x1 > #define DEVFREQ_GOV_STOP 0x2 > #define DEVFREQ_GOV_LIMITS 0x3 > +#define DEVFREQ_GOV_SUSPEND 0x4 > +#define DEVFREQ_GOV_RESUME 0x5 > > /** > * struct devfreq_dev_profile - Devfreq's user device profile > @@ -155,6 +157,10 @@ extern struct devfreq *devfreq_add_device(struct device *dev, > void *data); > extern int devfreq_remove_device(struct devfreq *devfreq); > > +extern int devfreq_suspend_device(struct devfreq *devfreq); > + > +extern int devfreq_resume_device(struct devfreq *devfreq); > + > /* Helper functions for devfreq user device driver with OPP. */ > extern struct opp *devfreq_recommended_opp(struct device *dev, > unsigned long *freq, u32 flags); > @@ -207,6 +213,16 @@ static int devfreq_remove_device(struct devfreq *devfreq) > return 0; > } > > +static int devfreq_suspend_device(struct devfreq *devfreq) > +{ > + return 0; > +} > + > +extern int devfreq_resume_device(struct devfreq *devfreq) > +{ > + return 0; > +} > + > static struct opp *devfreq_recommended_opp(struct device *dev, > unsigned long *freq, u32 flags) > { > -- > 1.7.11.3 >

12 years, 4 months

Re: [PATCH 1/3][RFC] devfreq: Core updates to support devices which can idle

by 함명주

> 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.) > - 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. > - 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. In this patchset, the size of ondemand governor has been enlarged too much for that purpose. > - 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? > > 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. 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)

12 years, 4 months

Re: [PATCH 3/3][RFC] devfreq: Add current freq callback in device profile

by 함명주

> 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". 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 > > > > > > > >

12 years, 4 months

[PATCH 0/3][RFC] devfreq: Add support for devices which can idle

by Rajagopal Venkat

This patchset updates devfreq core to add support for 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. patch 1 adds core design changes mainly moving monitoring logic to ondemand governor, introducing per device work and events for core to governor communication. patch 2 adds devfreq suspend and resume apis. patch 3 does current frequency bug fix. The existing devfreq apis are kept intact. Two new apis devfreq_suspend_device() and devfreq_resume_device() are added to support suspend/resume of device devfreq. -- Rajagopal Venkat (3): devfreq: core updates to support devices which can idle devfreq: Add suspend and resume apis devfreq: Add current freq callback in device profile Documentation/ABI/testing/sysfs-class-devfreq | 33 +- drivers/devfreq/devfreq.c | 448 ++++++-------------------- drivers/devfreq/governor.h | 6 +- drivers/devfreq/governor_performance.c | 34 +- drivers/devfreq/governor_powersave.c | 31 +- drivers/devfreq/governor_simpleondemand.c | 231 +++++++++++-- drivers/devfreq/governor_userspace.c | 142 ++++---- include/linux/devfreq.h | 78 +++-- 8 files changed, 467 insertions(+), 536 deletions(-) -- 1.7.11.3

12 years, 4 months

Virtual Connect Aftermath

by Christian Robottom Reis

Hello there, Last week we ran a series of open sessions as part of an experimental Virtual Linaro Connect schedule; the blog post announcing it is at: http://www.linaro.org/linaro-blog/2012/08/07/linaro-announces-virtual-conne… We ran all the sessions successfully over a combination of Google Hangouts, IRC and Etherpad, and the videos are now all available for your review and comments at: http://www.youtube.com/channel/UCIVqQKxCyQLJS6xvSmfndLA?feature=guideo If there anything on the menu that interests you, it's worth taking a look at the sessions. The minutes linked to from the video pages are also a good trove of information and can be used to follow the dialogue which is sometimes a bit tricky. We're considering running a wider Virtual Connect now that this one has concluded successfully; I'd love to hear your feedback on how it went and what you'd like to see us do differently for future events. Thanks! -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs

12 years, 4 months

[PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP

by Sangwook Lee

The following 2 patches add driver for S5K4ECGX sensor with embedded ISP SoC, and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor from Samsung Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc Changes since v1: - fixed s_stream(0) when it called twice - changed mutex_X position to be used when strictly necessary - add additional s_power(0) in case that error happens - update more accurate debugging statements - remove dummy else Sangwook Lee (2): v4l: Add factory register values form S5K4ECGX sensor v4l: Add v4l2 subdev driver for S5K4ECGX sensor drivers/media/video/Kconfig | 8 + drivers/media/video/Makefile | 1 + drivers/media/video/s5k4ecgx.c | 839 ++++++++++ drivers/media/video/s5k4ecgx_regs.h | 3105 +++++++++++++++++++++++++++++++++++ include/media/s5k4ecgx.h | 39 + 5 files changed, 3992 insertions(+) create mode 100644 drivers/media/video/s5k4ecgx.c create mode 100644 drivers/media/video/s5k4ecgx_regs.h create mode 100644 include/media/s5k4ecgx.h -- 1.7.9.5

12 years, 4 months

Change in floating point performance across kernels

by Michael Hope

Hi there. I'm seeing a huge improvement in the SPEC floating point benchmarks between a hacked Ubuntu Precise 3.2.14 kernel and Linus 3.5. Does anyone know why off the top of their head? I see the same on a PandaBoard and PandaBoard ES. In both cases the CPU is locked to 1 GHz and other power management features are disabled. -- Michael

12 years, 4 months

handy script: editing uinitrd file

by Andy Doan

I've seen questions in the past about how to make quick changes to a uInitrd file. I hit the need to make a few changes today, and wrote a quick script others might find useful: http://people.linaro.org/~doanac/uinitrd.py Basically it extracts things to a temp directory, drops you into a shell where you can make changes, and then packages everything back up when you exit the shell. YMMV -andy

12 years, 4 months

New fast models device-tree topic for linux-linaro

by Jon Medhurst (Tixy)

Hi Andrey Can you include a new topic to linux-linaro which contains device-tree files for ARM's fast models? This branch is tracking-armlt-rtsm [1] in the ARM LT working tree. Thanks For those interested... These device-trees enable the the current Linaro vexpress kernel to boot on fast-models when used with the boot-wrapper at [2], this includes having a working display. However, on the big.LITLE models the A7 cores don't start, giving "Failed to boot -38". -- Tixy [1] http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=short… [2] http://git.linaro.org/gitweb?p=arm/models/boot-wrapper.git;a=summary

12 years, 4 months

Re: TI LT Android for Panda board and perf

by Dmitry Antipov

On 08/15/2012 06:56 PM, Shubhrajyoti wrote: > How can I build perf myself? > I tried cross compiling but failed...:-( > what are the steps? Cross-compiling is tricky because perf requires a lot of libraries. I do it natively, using Ubuntu developer image. Also note that perf can't be compiled outside of the kernel source tree, so you should copy the full tree to your target. Yes, this is ugly. Dmitry

12 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2012