Re: Are we going to start using config fragments?
On Thu, 2012-06-07 at 12:45 -0700, John Stultz wrote: > Tixy: My attention on this issue has been somewhat limited. You've been > by far the most involved in helping deploy config fragments (though, I > don't want to be punishing good behavior by suggesting this, so feel > free to say no! :), would you be interested in maintaining the branch? Yes, I volunteer. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
Hi John, On 06/07/2012 11:45 PM, John Stultz wrote: On 06/06/2012 07:09 AM, Jon Medhurst (Tixy) wrote: Are we going to start using the config fragments we created a while ago? (Or did we not reach consensus on that?) I wouldn't say there was a strong consensus. But I think we should push to make it available at an infrastructure level so those who do want to use it can. If we could get them into a 'final' git location and start using them for Ubuntu packaging, I can arrange for a mechanism to enable Android builds to use them. Andrey, where would a good "final" git location be so that the base config fragments could be included into the linaro-base tree? I can generate a new git tree, so its not just a branch in git://git.linaro.org/people/jstultz/android.git, but if you have other suggestions I'd welcome it. New tree would be great, as having the config fragments in android.git is a bit confusing. As for the location, guess it should be under git://git.linaro.org/kernel , but I would be ok with git://git.linaro.org/people/whoever if there are problems with getting it under git://git.linaro.org/kernel Tixy: My attention on this issue has been somewhat limited. You've been by far the most involved in helping deploy config fragments (though, I don't want to be punishing good behavior by suggesting this, so feel free to say no! :), would you be interested in maintaining the branch? I have attached a couple of patches for the config fragments (3.5 removed the PERF_COUNTERS config). Thanks, I'll create a new branch for 3.5 and merge your changes, so they don't get lost. thanks -john Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ci.linaro.org planned downtime
Hi all, It is our intention to take https://ci.linaro.org offline for about 15 minutes at 12:00 UTC (http://www.worldtimeserver.com/current_time_in_UTC.aspx) in an effort to fix https://bugs.launchpad.net/linaro-ci/+bug/959945 . If the downtime will cause you significant problems, please get in touch and we will arrange a better time. Thanks, Stevan ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] perf report: fix event name reporting
Use trace_find_event to find event name before looking through
/sys files. This helps 'perf report' to show real event names
instead of 'unknown:unknown' when processing perf.data recorded
on another machine.
Signed-off-by: Dmitry Antipov
---
tools/perf/builtin-report.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 8c767c6..a6fd309 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -24,6 +24,7 @@
#include "util/evlist.h"
#include "util/evsel.h"
#include "util/header.h"
+#include "util/trace-event.h"
#include "util/session.h"
#include "util/tool.h"
@@ -314,7 +315,8 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist
*evlist,
list_for_each_entry(pos, &evlist->entries, node) {
struct hists *hists = &pos->hists;
- const char *evname = event_name(pos);
+ struct event_format *event = trace_find_event(pos->attr.config);
+ const char *evname = event ? event->name : event_name(pos);
hists__fprintf_nr_sample_events(hists, evname, stdout);
hists__fprintf(hists, NULL, false, true, 0, 0, stdout);
--
1.7.7.6
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Call for topics for the 12.06 linux-linaro* trees
Greetings, There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels. In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. Probably more LT tracking trees would be added, but I am not sure due to the different bases the others use. Each LT's tracking tree act as a topic here, so the call for topics doesn't apply to this tree. linux-linaro-core-tracking tree is moving to 3.5 (but not published at git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been created. This is a copy of the most recent v3.4 based linux-linaro-core-tracking tree. *New generic (not board specific) topics and updates to the existing topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The current topics are: * arm_soc/testing/multiplatform * svenkatr/ufs-for-linux-linaro * svenkatr/emmc-for-linux-linaro * amitdanielk/thermal_exynos4_imx6_work * android_jstultz/linaro-android-3.5-jstultz-rebase * lt_arm/tracking-armlt-gator * umm_sumitsemwal/umm-3.4-wip (needs updating to 3.5?) * lt_samsung/llt/umm_fixes (should be better included into the topic above?) * android_jstultz/linaro-configs-3.5 * ll_quantal/linaro-ubuntu-sauce-packaging-topic (needs updating to 3.5?) linux-linaro tree will also move to 3.5. At the time of the 12.06 kernel release, it should be at v3.5-rc2 or v3.5-rc3. For those who are on v3.4, there is linux-linaro_3.4-2012.05-1 branch. *The landing teams*: - please let me know if you want your topics to be carried over to 3.5 based linux-linaro tree. - as usual, LT's topics updates and new topics (if any) are welcomed for both 3.5 based, and probably 3.4 based linux-linaro trees. If it turns out that the 3.4 based linux-linaro tree needs to be updated, I'll create a new branch from linux-linaro_3.4-2012.05-1. Sorry in advance for all the confusion which this post could introduce :) Please don't hesitate to comment on it, or to make corrections. Sometimes this could be just me not being clear enough. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
On Thu, 2012-06-07 at 12:45 -0700, John Stultz wrote: > On 06/06/2012 07:09 AM, Jon Medhurst (Tixy) wrote: > > Are we going to start using the config fragments we created a while ago? > > (Or did we not reach consensus on that?) > I wouldn't say there was a strong consensus. But I think we should push > to make it available at an infrastructure level so those who do want to > use it can. Actually, I just went back a re-read the old thread about config fragments. I can't seem to find anything like a consensus, but I don't want to give up, so here is what I plan to do... Create a git repo, (kernel/configs.git ?) Have a branch called config-core-tracking which will contain linaro-base.conf ubuntu.conf android.conf the idea being that this is a topic branch to pull into linux-linaro-core-tracking. I'll also keep config-core-3.X branches for previous linux versions, so people lagging tip have access to them. I'll put the vexpress/origen/imx5 fragments into a branch called config-boards-tracking so they are available to experiment with. Though I believe that any Landing Team wanting to use config fragments for their kernel would want to add their fragment to their working tree as a topic instead. Now, if the Ubuntu kernel packaging scripts could gain an option to generate a config from these fragments... :-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for topics for the 12.06 linux-linaro* trees
On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included: Greetings, There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels. In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. For reference the TI + Samsung trees I did during Connect can be found here: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/unify-samsung-ti This builds and works for OMAP at least. Probably more LT tracking trees would be added, but I am not sure due to the different bases the others use. Each LT's tracking tree act as a topic here, so the call for topics doesn't apply to this tree. linux-linaro-core-tracking tree is moving to 3.5 (but not published at git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been created. This is a copy of the most recent v3.4 based linux-linaro-core-tracking tree. *New generic (not board specific) topics and updates to the existing topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The current topics are: * arm_soc/testing/multiplatform * svenkatr/ufs-for-linux-linaro * svenkatr/emmc-for-linux-linaro * amitdanielk/thermal_exynos4_imx6_work Not sure if this will now already have it, but this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was tracking-thermal_exynos4_imx6-3.4-2012.05 had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
On Fri, Jun 8, 2012 at 7:07 AM, Jon Medhurst (Tixy) wrote: > On Thu, 2012-06-07 at 12:45 -0700, John Stultz wrote: >> On 06/06/2012 07:09 AM, Jon Medhurst (Tixy) wrote: >> > Are we going to start using the config fragments we created a while ago? >> > (Or did we not reach consensus on that?) >> I wouldn't say there was a strong consensus. But I think we should push >> to make it available at an infrastructure level so those who do want to >> use it can. > > Actually, I just went back a re-read the old thread about config > fragments. I can't seem to find anything like a consensus, but I don't > want to give up, so here is what I plan to do... > > Create a git repo, (kernel/configs.git ?) > > Have a branch called config-core-tracking which will contain > > linaro-base.conf > ubuntu.conf > android.conf I think I missed something in an earlier thread. If I merge this into a kernel tree do they land in the root of the tree, or are you going to prepend a directory? Also are these core and lt config fragment branches intended to be topics in Andrey's result tree? > > the idea being that this is a topic branch to pull into > linux-linaro-core-tracking. I'll also keep config-core-3.X branches for > previous linux versions, so people lagging tip have access to them. > > I'll put the vexpress/origen/imx5 fragments into a branch called > config-boards-tracking so they are available to experiment with. Though > I believe that any Landing Team wanting to use config fragments for > their kernel would want to add their fragment to their working tree as a > topic instead. > > Now, if the Ubuntu kernel packaging scripts could gain an option to > generate a config from these fragments... :-) > That will happen soon. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
On Fri, 2012-06-08 at 08:15 -0600, John Rigby wrote: > On Fri, Jun 8, 2012 at 7:07 AM, Jon Medhurst (Tixy) wrote: > > Have a branch called config-core-tracking which will contain > > > > linaro-base.conf > > ubuntu.conf > > android.conf > I think I missed something in an earlier thread. If I merge this into > a kernel tree do they land in the root of the tree, or are you going > to prepend a directory? They are currently in a directory called configs/. I was thinking that perhaps it should be something like linaro/configs/ to allow for other Linaro extras without poluting the root directory more, but couldn't think of a compelling reason to suggest this. > Also are these core and lt config fragment > branches intended to be topics in Andrey's result tree? The core fragments are intended to be part of linux-linaro-core-tracking (which Andrey maintains and is intended to be included into all Linaro kernels). The board specific config fragments should ideally be part of the Landing Team topics which are included in a kernel tree with the rest of their enablement topics. If that doesn't happen for whatever reason, we can have the board configs pulled from my new config-boards-* branch. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Virtual Keyboard Issue
Hi, Any clue or pointers to solve this issue? On Wed, Jun 6, 2012 at 5:37 PM, Bharathi Subramanian wrote: > Hi All, > > I am using Linaro 11.11 Gingerbread with 10" LCD and touchscreen. In > that, the Android Virtual Keyboard is not visible fully on the screen. > So unable to type Text in SMS or URL in Browser. Only 5mm of the > keyboard's top portion alone is visible. Any clue on how to fix this > issue? Is it related to IDC file? -- Bharathi Subramanian ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Virtual Keyboard Issue
Hi Bharathi, It is an issue with the soft keyboard. Can you install ICS keyboard apk . It should work well on GB releases. Regards, Vishal On 8 June 2012 20:38, Bharathi Subramanian wrote: > Hi, Any clue or pointers to solve this issue? > > On Wed, Jun 6, 2012 at 5:37 PM, Bharathi Subramanian wrote: > > Hi All, > > > > I am using Linaro 11.11 Gingerbread with 10" LCD and touchscreen. In > > that, the Android Virtual Keyboard is not visible fully on the screen. > > So unable to type Text in SMS or URL in Browser. Only 5mm of the > > keyboard's top portion alone is visible. Any clue on how to fix this > > issue? Is it related to IDC file? > > -- > Bharathi Subramanian > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
On Fri, 2012-06-08 at 08:15 -0600, John Rigby wrote: > On Fri, Jun 8, 2012 at 7:07 AM, Jon Medhurst (Tixy) wrote: > > Now, if the Ubuntu kernel packaging scripts could gain an option to > > generate a config from these fragments... :-) > > > That will happen soon. I should point out that at the moment we don't have config fragments for panda or snowball, and I don't know if the other teams are going to get involved. If it is difficult making config fragment use optional, I could reverse engineer fragments for these boards from the current configs used for Ubuntu. (I am assuming that configs are currently hard coded in the kernel packaging scripts and not generated from another source?) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Are we going to start using config fragments?
On Fri, Jun 8, 2012 at 9:25 AM, Jon Medhurst (Tixy) wrote: > On Fri, 2012-06-08 at 08:15 -0600, John Rigby wrote: >> On Fri, Jun 8, 2012 at 7:07 AM, Jon Medhurst (Tixy) wrote: > >> > Now, if the Ubuntu kernel packaging scripts could gain an option to >> > generate a config from these fragments... :-) >> > >> That will happen soon. > > I should point out that at the moment we don't have config fragments for > panda or snowball, and I don't know if the other teams are going to get > involved. If it is difficult making config fragment use optional, I > could reverse engineer fragments for these boards from the current > configs used for Ubuntu. (I am assuming that configs are currently hard > coded in the kernel packaging scripts and not generated from another > source?) For lt kernels we get configs from the here: http://git.linaro.org/gitweb?p=people/jcrigby/linux-lt-ci-pack-info.git;a=heads I intend to ignore those in the new scripts if the config fragments exist so we can support both methods at first until we get config fragments for all kernels. For non lt kernels the configs are in the packaging. This bad to have linux-linaro work differently that lt and I will be making all things the same soon. --john > > -- > Tixy > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC 3/4] cpuidle : move tlb flag to the cpuidle header
Move this specific flag to the header file.
Signed-off-by: Daniel Lezcano
---
drivers/idle/intel_idle.c |8
include/linux/cpuidle.h |7 +++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index d0f59c3..3456fc9 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -100,14 +100,6 @@ static int intel_idle(struct cpuidle_device *dev,
static struct cpuidle_state *cpuidle_state_table;
/*
- * Set this flag for states where the HW flushes the TLB for us
- * and so we don't need cross-calls to keep it consistent.
- * If this flag is set, SW flushes the TLB, so even if the
- * HW doesn't do the flushing, this flag is safe to use.
- */
-#define CPUIDLE_FLAG_TLB_FLUSHED 0x1
-
-/*
* States are indexed by the cstate number,
* which is also the index into the MWAIT hint array.
* Thus C0 is a dummy.
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index f5915e9..aafacd4 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -64,9 +64,16 @@ struct cpuidle_state {
*the cpuidle core the specified state can use the
*
*enter_dead function.
*
*
*
+ * CPUIDLE_FLAG_TLB_FLUSHED : Set this flag for states where the HW flushes
the *
+ *TLB for us and so we don't need cross-calls to
*
+ *keep it consistent. If this flag is set, SW
*
+ *flushes the TLB, so even if the HW doesn't do
the *
+ *flushing, this flag is safe to use.
*
+ *
*
***/
#define CPUIDLE_FLAG_TIME_VALID 0x01
#define CPUIDLE_FLAG_DEAD_VALID 0x02
+#define CPUIDLE_FLAG_TLB_FLUSHED 0x04
/**
* cpuidle_get_statedata - retrieves private driver state data
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC 1/4] cpuidle: define the enter function in the driver structure
We have the state index passed as parameter to the 'enter' function.
Most of the drivers assign their 'enter' functions several times in
the cpuidle_state structure, as we have the index, we can delegate
to the driver to handle their own callback array.
That will have the benefit of removing multiple lines of code in the
different drivers.
In order to smoothly modify the driver, the 'enter' function are in
the driver structure and in the cpuidle state structure. That will
let the time to modify the different drivers one by one.
So the 'cpuidle_enter' function checks if the 'enter' callback is
assigned in the driver structure and use it, otherwise it invokes
the 'enter' assigned to the cpuidle_state.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/cpuidle.c |4 +++-
include/linux/cpuidle.h |1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d90519c..155dee7 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -46,7 +46,9 @@ static inline int cpuidle_enter(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
struct cpuidle_state *target_state = &drv->states[index];
- return target_state->enter(dev, drv, index);
+
+ return drv->enter(dev, drv, index) ? drv->enter(dev, drv, index) :
+ target_state->enter(dev, drv, index);
}
static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 6c26a3d..d82e169 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -130,6 +130,7 @@ struct cpuidle_driver {
struct cpuidle_statestates[CPUIDLE_STATE_MAX];
int state_count;
int safe_state_index;
+ int (*enter)(struct cpuidle_device *, struct cpuidle_driver *, int);
};
#ifdef CONFIG_CPU_IDLE
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC 4/4] cpuidle: replace the 'disable' field by a flag
We have a flag field for each cpuidle state but we don't use it
for the 'disabled' states. Let's remove the integer field and use
the flag field.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/cpuidle.c|1 -
drivers/cpuidle/governors/menu.c |5 +++--
drivers/cpuidle/sysfs.c |4 ++--
include/linux/cpuidle.h |4 +++-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 68bf115..3068b65 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -267,7 +267,6 @@ static void poll_idle_init(struct cpuidle_driver *drv)
state->power_usage = -1;
state->flags = 0;
state->enter = poll_idle;
- state->disable = 0;
}
#else
static void poll_idle_init(struct cpuidle_driver *drv) {}
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 0633575..c1fe87b 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -281,7 +281,8 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
* unless the timer is happening really really soon.
*/
if (data->expected_us > 5 &&
- drv->states[CPUIDLE_DRIVER_STATE_START].disable == 0)
+ !(drv->states[CPUIDLE_DRIVER_STATE_START].flags &
+ CPUIDLE_FLAG_DISABLED))
data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
/*
@@ -291,7 +292,7 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
struct cpuidle_state *s = &drv->states[i];
- if (s->disable)
+ if (s->flags & CPUIDLE_FLAG_DISABLED)
continue;
if (s->target_residency > data->predicted_us)
continue;
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 88032b4..a9a5f05 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -245,9 +245,9 @@ static ssize_t store_state_##_name(struct cpuidle_state
*state, \
if (err) \
return err; \
if (value) \
- state->disable = 1; \
+ state->flags |= CPUIDLE_FLAG_DISABLED; \
else \
- state->disable = 0; \
+ state->flags &= ~CPUIDLE_FLAG_DISABLED; \
return size; \
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index aafacd4..65f4c52 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -46,7 +46,6 @@ struct cpuidle_state {
unsigned intexit_latency; /* in US */
int power_usage; /* in mW */
unsigned inttarget_residency; /* in US */
- unsigned intdisable;
int (*enter)(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
@@ -70,10 +69,13 @@ struct cpuidle_state {
*flushes the TLB, so even if the HW doesn't do
the *
*flushing, this flag is safe to use.
*
*
*
+ * CPUIDLE_FLAG_DISABLE : the state is disabled if this flag is set
*
+ *
*
***/
#define CPUIDLE_FLAG_TIME_VALID 0x01
#define CPUIDLE_FLAG_DEAD_VALID 0x02
#define CPUIDLE_FLAG_TLB_FLUSHED 0x04
+#define CPUIDLE_FLAG_DISABLED0x08
/**
* cpuidle_get_statedata - retrieves private driver state data
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC 2/4] cpuidle: move enter_dead to the driver structure
The 'enter_dead' function is only used for processor_idle.c
and the same function is used several times. We fall into the
same abuse with the multiple callbacks for the same function.
This patch fixes that by moving the 'enter_dead' function to the
driver structure. A flag CPUIDLE_FLAG_DEAD_VALID has been added
to handle the callback conditional invokation.
Signed-off-by: Daniel Lezcano
---
drivers/acpi/processor_idle.c |7 +++
drivers/cpuidle/cpuidle.c |4 ++--
include/linux/cpuidle.h | 25 +
3 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index f3decb3..5590ab4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -996,6 +996,7 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
struct cpuidle_driver acpi_idle_driver = {
.name = "acpi_idle",
.owner =THIS_MODULE,
+ .enter_dead = acpi_idle_play_dead,
};
/**
@@ -1104,16 +1105,14 @@ static int acpi_processor_setup_cpuidle_states(struct
acpi_processor *pr)
case ACPI_STATE_C1:
if (cx->entry_method == ACPI_CSTATE_FFH)
state->flags |= CPUIDLE_FLAG_TIME_VALID;
-
+ state->flags |= CPUIDLE_FLAG_DEAD_VALID;
state->enter = acpi_idle_enter_c1;
- state->enter_dead = acpi_idle_play_dead;
drv->safe_state_index = count;
break;
case ACPI_STATE_C2:
- state->flags |= CPUIDLE_FLAG_TIME_VALID;
+ state->flags |= CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_DEAD_VALID;
state->enter = acpi_idle_enter_simple;
- state->enter_dead = acpi_idle_play_dead;
drv->safe_state_index = count;
break;
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 155dee7..68bf115 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -81,14 +81,14 @@ int cpuidle_play_dead(void)
for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
struct cpuidle_state *s = &drv->states[i];
- if (s->power_usage < power_usage && s->enter_dead) {
+ if (s->power_usage < power_usage && (s->flags &
CPUIDLE_FLAG_DEAD_VALID)) {
power_usage = s->power_usage;
dead_state = i;
}
}
if (dead_state != -1)
- return drv->states[dead_state].enter_dead(dev, dead_state);
+ return drv->enter_dead(dev, dead_state);
return -ENODEV;
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index d82e169..f5915e9 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -49,16 +49,24 @@ struct cpuidle_state {
unsigned intdisable;
int (*enter)(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index);
-
- int (*enter_dead) (struct cpuidle_device *dev, int index);
+struct cpuidle_driver *drv,
+int index);
};
-/* Idle State Flags */
-#define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable?
*/
-
-#define CPUIDLE_DRIVER_FLAGS_MASK (0x)
+/
+ * Idle State Flags:
*
+ * CPUIDLE_FLAG_TIME_VALID : the drivers could measure the state residency
*
+ *time and store it in the
'target_residency'field. *
+ *This flag will tell the cpuidle core to use this
*
+ *value to compute an accurate prediction.
*
+ *
*
+ * CPUIDLE_FLAG_DEAD_VALID : the driver may want to deal with dead cpus, tell
*
+ *the cpuidle core the specified state can use the
*
+ *enter_dead function.
*
+ *
*
+
***/
+#define CPUIDLE_FLAG_TIME_VALID 0x01
+#define CPUIDLE_FLAG_DEAD_VALID 0x02
/**
* cpuidle_get_statedata - retrieves private driver state data
@@ -131,6 +139,7 @@ struct cpuidle_driver {
int state_count;
int safe_state_index;
int (*enter)(struct cpuidle_device *, struct cpuidle_driver *, int);
+ int (*enter_dead)(struct cpuidle_device *, int);
};
#ifdef CONFIG_CPU_IDLE
--
1.7.5.4
__
Re: [linux-pm] [RFC 1/4] cpuidle: define the enter function in the driver structure
Hi Daniel,
On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
> We have the state index passed as parameter to the 'enter' function.
> Most of the drivers assign their 'enter' functions several times in
> the cpuidle_state structure, as we have the index, we can delegate
> to the driver to handle their own callback array.
>
> That will have the benefit of removing multiple lines of code in the
> different drivers.
>
> In order to smoothly modify the driver, the 'enter' function are in
> the driver structure and in the cpuidle state structure. That will
> let the time to modify the different drivers one by one.
> So the 'cpuidle_enter' function checks if the 'enter' callback is
> assigned in the driver structure and use it, otherwise it invokes
> the 'enter' assigned to the cpuidle_state.
Currently, the backend driver initializes
all the cpuidle states supported on the platform,
and each state can have its own enter routine
which can be unique This is a clean approach.
By moving the enter routine into the driver,
we are enforcing in having only one enter state.
There is unnecessary overhead involved
in calling a wrapper routine just to
index into the right idle state routine
for many platforms at runtime.
> Signed-off-by: Daniel Lezcano
> ---
> drivers/cpuidle/cpuidle.c |4 +++-
> include/linux/cpuidle.h |1 +
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index d90519c..155dee7 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -46,7 +46,9 @@ static inline int cpuidle_enter(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index)
> {
> struct cpuidle_state *target_state = &drv->states[index];
> - return target_state->enter(dev, drv, index);
> +
> + return drv->enter(dev, drv, index) ? drv->enter(dev, drv, index) :
> + target_state->enter(dev, drv, index);
> }
>
> static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 6c26a3d..d82e169 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -130,6 +130,7 @@ struct cpuidle_driver {
> struct cpuidle_statestates[CPUIDLE_STATE_MAX];
> int state_count;
> int safe_state_index;
> + int (*enter)(struct cpuidle_device *, struct cpuidle_driver *, int);
> };
>
> #ifdef CONFIG_CPU_IDLE
Cheers,
Deepthi
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [RFC 1/4] cpuidle: define the enter function in the driver structure
On 06/08/2012 07:33 PM, Deepthi Dharwar wrote: > Hi Daniel, Hi Deepthi, > On 06/08/2012 09:32 PM, Daniel Lezcano wrote: > >> We have the state index passed as parameter to the 'enter' function. >> Most of the drivers assign their 'enter' functions several times in >> the cpuidle_state structure, as we have the index, we can delegate >> to the driver to handle their own callback array. >> >> That will have the benefit of removing multiple lines of code in the >> different drivers. >> >> In order to smoothly modify the driver, the 'enter' function are in >> the driver structure and in the cpuidle state structure. That will >> let the time to modify the different drivers one by one. >> So the 'cpuidle_enter' function checks if the 'enter' callback is >> assigned in the driver structure and use it, otherwise it invokes >> the 'enter' assigned to the cpuidle_state. > > > Currently, the backend driver initializes > all the cpuidle states supported on the platform, > and each state can have its own enter routine > which can be unique This is a clean approach. Yes, I perfectly understood the purpose of this field but as clean it is it does not make sense as it is not used in this way. If it is supposed to be done in the way you are describing here, we should have the same number of states and enter functions. Here it is how it is used: -- | Arch | nr states | nr enter function | -- | x86 (nehalem)|3 | 1 | -- | x86 (snb)|4 | 1 | -- | x86 (atom) |4 | 1 | -- | ARM tegra|1 | 1 | -- | ARM omap3|7 | 2 | -- | ARM omap4|3 | 1 | -- | ARM ux500|2 | 1 | -- | ARM shmobile |1 | 1 | -- | ARM davinci |2 | 1 | -- | ARM at91 |2 | 1 | -- | ARM s3c64xx |1 | 1 | -- | ARM exynos |2 | 1 | -- | ARM kirkwood |2 | 1 | -- | SH |3 | 1 | -- | PPC |2 | 2 | -- | | | | | TOTAL|39 |17 | | | | | -- As you can see most of the enter functions are only used as one. The Omap3 cpuidle driver enter function for C2 calls the enter function of C1. Other arch, already use a table of callbacks or the index. > By moving the enter routine into the driver, > we are enforcing in having only one enter state. > There is unnecessary overhead involved > in calling a wrapper routine just to > index into the right idle state routine > for many platforms at runtime. I don't agree. For the sake of encapsulated code, we duplicate n-times a field and that is not used in this way. It is quite easy to have in the driver specific code a common enter function to ventilate to the right routine without adding extra overhead and let the common code use a single enter routine (which is already the case today). ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
