Re: [RFC] Scheduler recorder and playback
On 04/04/2012 05:10 PM, Pantelis Antoniou wrote: The reason for the slowdown is that perf sched record default settings is tuned for x86 pretty much, and there's a huge amount of data being generated. perf sched record is just a wrapper for perf record so try using this script for recording: #!/bin/sh perf record \ -a \ -R \ -f \ -m 8192 \ -c 1 \ -e sched:sched_switch \ -e sched:sched_process_exit \ -e sched:sched_process_fork \ -e sched:sched_wakeup \ -e sched:sched_migrate_task That's OK, but I got the following assertion while processing with 'perf sched spr-replay -l': perf: builtin-sched.c:2629: execute_wait_id: Assertion `ret == 0 || ret == 11' failed. The program continues, but may report a tens of these assertions. And one more question around threads. I'm trying to record/replay a test application based on WebKit framework, which tends to spawn a service threads from time to time. So, 'perf sched spr-replay -l' output may looks like the following: [perf/1503] [kworker/0:2/1439] [ksoftirqd/0/3] [testbrowser/1504] [swapper/1/0] [kworker/1:2/1437] [sshd/1232] [testbrowser/1505] [testbrowser/1506] [ksoftirqd/1/9] [testbrowser/1507] [testbrowser/1508] [sync_supers/179] [testbrowser/1509] [testbrowser/1510] [testbrowser/1511] [testbrowser/1512] [testbrowser/1513] [testbrowser/1514] [testbrowser/1515] [testbrowser/1516] [testbrowser/1517] [testbrowser/1518] [testbrowser/1519] [testbrowser/1520] [testbrowser/1521] [testbrowser/1522] [testbrowser/1523] [testbrowser/1524] [testbrowser/1525] [testbrowser/1526] [testbrowser/1527] [testbrowser/1528] [testbrowser/1529] [testbrowser/1530] [testbrowser/1531] [testbrowser/1532] [testbrowser/1533] [testbrowser/1534] [testbrowser/1535] [testbrowser/1536] [testbrowser/1537] [testbrowser/1538] [testbrowser/1539] [testbrowser/1540] [testbrowser/1541] [testbrowser/1542] [testbrowser/1543] [testbrowser/1544] [testbrowser/1545] [testbrowser/1546] [testbrowser/1547] [testbrowser/1548] [testbrowser/1549] [testbrowser/1550] [testbrowser/1551] [testbrowser/1552] [testbrowser/1553] [testbrowser/1554] [testbrowser/1555] [flush-179:0/1480] [testbrowser/1556] [testbrowser/1557] [kjournald/510] [mmcqd/0/499] [khungtaskd/347] [testbrowser/1558] [testbrowser/1559] [testbrowser/1560] [testbrowser/1561] [testbrowser/1562] [testbrowser/1563] [rsyslogd/573] [testbrowser/1564] [testbrowser/1565] [testbrowser/1566] [testbrowser/1567] [testbrowser/1568] [testbrowser/1569] [testbrowser/1570] [testbrowser/1571] [testbrowser/1572] [testbrowser/1573] [testbrowser/1574] [testbrowser/1575] [testbrowser/1576] [testbrowser/1577] [testbrowser/1578] [testbrowser/1579] [testbrowser/1580] [testbrowser/1581] [testbrowser/1582] [testbrowser/1583] [testbrowser/1584] [testbrowser/1585] [testbrowser/1586] [testbrowser/1587] [testbrowser/1588] [testbrowser/1589] [testbrowser/1590] [testbrowser/1591] [testbrowser/1592] [testbrowser/1593] [testbrowser/1594] [cron/1109] [testbrowser/1595] [testbrowser/1596] [testbrowser/1597] [testbrowser/1598] [testbrowser/1599] [testbrowser/1600] [testbrowser/1601] [testbrowser/1602] [testbrowser/1603] [testbrowser/1604] [testbrowser/1605] [testbrowser/1606] [testbrowser/1607] [testbrowser/1608] [testbrowser/1609] [testbrowser/1610] [testbrowser/1611] [testbrowser/1612] [testbrowser/1613] [testbrowser/1614] [testbrowser/1615] [testbrowser/1616] [testbrowser/1617] [testbrowser/1618] [testbrowser/1619] [testbrowser/1620] [testbrowser/1621] [testbrowser/1622] [testbrowser/1623] [testbrowser/1624] [testbrowser/1625] [testbrowser/1626] [testbrowser/1627] [testbrowser/1628] [testbrowser/1629] There are a lot of threads created by main thread [testbrowser/1504]. Is there a way to find the most advanced CPU heaters among them? Dmitry ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Scheduler recorder and playback
Hi Dmitry, On Apr 9, 2012, at 1:07 PM, Dmitry Antipov wrote: > On 04/04/2012 05:10 PM, Pantelis Antoniou wrote: > >> The reason for the slowdown is that perf sched record default settings is >> tuned for x86 pretty much, and there's a huge amount of data being generated. >> >> perf sched record is just a wrapper for perf record so try using this script >> for recording: >> >>> #!/bin/sh >>> perf record \ >>> -a \ >>> -R \ >>> -f \ >>> -m 8192 \ >>> -c 1 \ >>> -e sched:sched_switch \ >>> -e sched:sched_process_exit \ >>> -e sched:sched_process_fork \ >>> -e sched:sched_wakeup \ >>> -e sched:sched_migrate_task > > That's OK, but I got the following assertion while processing with 'perf > sched spr-replay -l': > OK > perf: builtin-sched.c:2629: execute_wait_id: Assertion `ret == 0 || ret == > 11' failed. > Hmm, futex op fails? Mind sending me the trace file to test locally? > The program continues, but may report a tens of these assertions. > > And one more question around threads. I'm trying to record/replay a test > application > based on WebKit framework, which tends to spawn a service threads from time > to time. > So, 'perf sched spr-replay -l' output may looks like the following: > > [perf/1503] > [kworker/0:2/1439] > [ksoftirqd/0/3] > [testbrowser/1504] > [swapper/1/0] > [kworker/1:2/1437] > [sshd/1232] > [testbrowser/1505] > [testbrowser/1506] > [ksoftirqd/1/9] > [testbrowser/1507] > [testbrowser/1508] > [sync_supers/179] > [testbrowser/1509] > [testbrowser/1510] > [testbrowser/1511] > [testbrowser/1512] > [testbrowser/1513] > [testbrowser/1514] > [testbrowser/1515] > [testbrowser/1516] > [testbrowser/1517] > [testbrowser/1518] > [testbrowser/1519] > [testbrowser/1520] > [testbrowser/1521] > [testbrowser/1522] > [testbrowser/1523] > [testbrowser/1524] > [testbrowser/1525] > [testbrowser/1526] > [testbrowser/1527] > [testbrowser/1528] > [testbrowser/1529] > [testbrowser/1530] > [testbrowser/1531] > [testbrowser/1532] > [testbrowser/1533] > [testbrowser/1534] > [testbrowser/1535] > [testbrowser/1536] > [testbrowser/1537] > [testbrowser/1538] > [testbrowser/1539] > [testbrowser/1540] > [testbrowser/1541] > [testbrowser/1542] > [testbrowser/1543] > [testbrowser/1544] > [testbrowser/1545] > [testbrowser/1546] > [testbrowser/1547] > [testbrowser/1548] > [testbrowser/1549] > [testbrowser/1550] > [testbrowser/1551] > [testbrowser/1552] > [testbrowser/1553] > [testbrowser/1554] > [testbrowser/1555] > [flush-179:0/1480] > [testbrowser/1556] > [testbrowser/1557] > [kjournald/510] > [mmcqd/0/499] > [khungtaskd/347] > [testbrowser/1558] > [testbrowser/1559] > [testbrowser/1560] > [testbrowser/1561] > [testbrowser/1562] > [testbrowser/1563] > [rsyslogd/573] > [testbrowser/1564] > [testbrowser/1565] > [testbrowser/1566] > [testbrowser/1567] > [testbrowser/1568] > [testbrowser/1569] > [testbrowser/1570] > [testbrowser/1571] > [testbrowser/1572] > [testbrowser/1573] > [testbrowser/1574] > [testbrowser/1575] > [testbrowser/1576] > [testbrowser/1577] > [testbrowser/1578] > [testbrowser/1579] > [testbrowser/1580] > [testbrowser/1581] > [testbrowser/1582] > [testbrowser/1583] > [testbrowser/1584] > [testbrowser/1585] > [testbrowser/1586] > [testbrowser/1587] > [testbrowser/1588] > [testbrowser/1589] > [testbrowser/1590] > [testbrowser/1591] > [testbrowser/1592] > [testbrowser/1593] > [testbrowser/1594] > [cron/1109] > [testbrowser/1595] > [testbrowser/1596] > [testbrowser/1597] > [testbrowser/1598] > [testbrowser/1599] > [testbrowser/1600] > [testbrowser/1601] > [testbrowser/1602] > [testbrowser/1603] > [testbrowser/1604] > [testbrowser/1605] > [testbrowser/1606] > [testbrowser/1607] > [testbrowser/1608] > [testbrowser/1609] > [testbrowser/1610] > [testbrowser/1611] > [testbrowser/1612] > [testbrowser/1613] > [testbrowser/1614] > [testbrowser/1615] > [testbrowser/1616] > [testbrowser/1617] > [testbrowser/1618] > [testbrowser/1619] > [testbrowser/1620] > [testbrowser/1621] > [testbrowser/1622] > [testbrowser/1623] > [testbrowser/1624] > [testbrowser/1625] > [testbrowser/1626] > [testbrowser/1627] > [testbrowser/1628] > [testbrowser/1629] > > There are a lot of threads created by main thread [testbrowser/1504]. Is > there a way > to find the most advanced CPU heaters among them? > I see your problem, I'll whip something to report the CPU accumulated run time per thread. > Dmitry Regards -- Pantelis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre wrote: > On Fri, 6 Apr 2012, Ricardo Salveti wrote: > >> On Fri, Apr 6, 2012 at 6:05 AM, Wookey wrote: >> > The fundamental question really is 'are we a distro or not'? If linaro >> > is not a distro then no-one should be expecting stable releases - we >> > are a technology showcase, and developer quick-start mechanism, and >> > the existing process seems reasonably appropriate for that, but if we >> > are expecting people to actually base real work off our outputs, then >> > he's right and we ought to change some things. >> >> It might be the same thing, but for me the question is really "do we >> care about users and we want people to use our LEBs?". If we assume >> the LEBs are just a bunch of evaluation images to be used internally >> to help improving the development and testing, then you could simply >> say that we're not any kind of distro. >> >> Now if we decide to have people using and consuming our LEBs (what I >> believe we do), then we need to think a bit further, and assume some >> extra responsibilities. We don't want to be a full distro, as we want >> to be flexible enough to break things once a while, but we really need >> to be aware that once we get users running our images, they will >> *expect* some sort of stability, putting us back as we were a distro >> :-) > > Stability is not sufficient. Users will also expect support, updates, > and security fixes, etc. And the more stable our stuff looks, the more > users and user demands we'll get. Fulfilling those user *expectations* > is hard and costly. Some companies are basing their entire business on > that, and they do a really great job already. > > We certainly don't shine at being a distro, and IMHO we shouldn't even > try. If some people want the latest cool stuff we provide that's fine, > but they should expect a shaky world. Existing distro people out there > will pick up our work too and stabilize it. In fact, they are > encouraged to do so. > > Stabilization takes time, which is why there is a delay before our stuff > is available through existing distros. There is simply no way around > that. Stable and latest bleeding edge are simply not compatible. If > Linaro is to produce stabilized releases, we'll introduce extra delays > too, and we'll consume a significant amount of development resources > doing that. > > Therefore I don't think we should duplicate what distro people are > already doing. That shouldn't be where our focus is. Expectations to > users should probably be clarified as well. That is fair.. there is no point duplicating what distro folks are already doing. It might be nice to do a better job of folding back bits and pieces of what we do into (for example) ubuntu PPA's.. for example, I think a number of people are trying linaro builds just because they want xbmc, not because they care about various other bleeding edge bits. Although, other than OMAP, are there ubuntu PPA's to get graphics, etc, accel for other member company platforms? Ie. when someone like the FXI cotton candy folks come along looking for a filesystem they can use on their product (where presumably they care more about enablement than bleeding edge), could we tell them to use ubuntu or AOSP or whatever? I'm just wondering if there is a good "one size fits all" answer.. if there isn't a member company supported PPA for ubuntu where you can get the gfx and/or multimedia blobs, then the only-bleeding-edge-devel filesystems approach might be leaving a bit of a gap for someone trying to make a product (which is, in the end, what we care about). BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Call for testing Linaro Android 12.04 candidates
We have prepared Linaro Android 12.04 candidates. Spreadsheets have been updated. Please, run the tests that have a 'w' after them. Thanks! Testers, builds and spreadsheets Jon https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE Chenglie https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-samsunglt-stable-blob-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDRDVl9TSHUweUk3eG9ndk9sNGxUVnc Bernard https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-freescalelt-stable-open-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1MlJmY19PQzlJOUY5OXk0SWJYT1E Vishal https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-tracking-blob-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E Botao https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1MlJmY19PQzlJOUY5OXk0SWJYT1E Mathieu https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob-12.04-release/ https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc Amit https://android-build.linaro.org/builds/~linaro-android/vexpress-rtsm-ics-gcc46-armlt-stable-open-12.04-release/ No spreadsheet for vexpress-rtsm build. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
qemu & hardware gfx acceleration
So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration? Unfortunately there's little technical details in the post above. The video is clearly running on OS X, so I'm not sure if this will also be usable w/ Linux hosts, but I could be wrong there. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: qemu & hardware gfx acceleration
On 10 April 2012 07:13, John Stultz wrote: > So the Google Android team just posted this: > http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html > > Which shows their device emulator running w/ hardware acceleration. Since I > know they started with qemu, I was curious if there was any details as to if > these sorts of changes were making it back upstream to qemu, or if qemu had > its own plans for hardware acceleration? > > Unfortunately there's little technical details in the post above. The video > is clearly running on OS X, so I'm not sure if this will also be usable w/ > Linux hosts, but I could be wrong there. Hi John. Peter can say more, but I think they've done two things: pass OpenGL operations through to the host and run a virtualised x86 Android image instead of a JITted ARM Android image. I don't know what's going upstream but the Google QEMU people are friendly and have cherry picked from us before. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro 12.04 3.4-rc1 based androidization branch is available
I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: qemu & hardware gfx acceleration
On 9 April 2012 20:13, John Stultz wrote: > So the Google Android team just posted this: > http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html > > Which shows their device emulator running w/ hardware acceleration. Since I > know they started with qemu, I was curious if there was any details as to if > these sorts of changes were making it back upstream to qemu, or if qemu had > its own plans for hardware acceleration? Unfortunately Google's Android emulator has diverged a lot from upstream QEMU, to the extent that I don't think it very likely that it will ever merge back again. (I'd love to be proved wrong, of course, but we had a look at adding basic support for the Goldfish virtual platform to upstream QEMU as part of a Google Summer of Code project last year, and it turns out that you would basically have to rewrite most of the device models to get anything upstream would accept as following current QEMU frameworks/APIs/etc. Since then the upstream QEMU API for device models has evolved again...) The idea of hardware graphics acceleration (ie OpenGL(ES) passthrough) for upstream QEMU has been discussed (and even the odd patch series or two has been submitted though not committed); but I think that there isn't anybody who wants it enough to be able to dedicate the time to thrashing out a design acceptable to everybody and getting it accepted by upstream. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 02/17][V2] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
Daniel Lezcano writes:
> The cpuidle API allows to declare statically the states in the driver
> structure. Let's use it.
> We do no longer need the fill_cstate function called at runtime and
> by the way adding more instructions at boot time.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> Reviewed-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 57 +---
> 1 files changed, 33 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index ee0bc50..6d86b59 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -132,21 +132,39 @@ struct cpuidle_driver omap4_idle_driver = {
> .name = "omap4_idle",
> .owner = THIS_MODULE,
> .en_core_tk_irqen = 1,
> + .states = {
> + {
> + /* C1 - CPU0 ON + CPU1 ON + MPU ON */
> + .exit_latency = 2 + 2,
> + .target_residency = 5,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .enter = omap4_enter_idle,
> + .name = "C1",
> + .desc = "MPUSS ON"
> + },
> + {
> +/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
> + .exit_latency = 328 + 440,
> + .target_residency = 960,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .enter = omap4_enter_idle,
> + .name = "C2",
> + .desc = "MPUSS CSWR",
> + },
> + {
> + /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
> + .exit_latency = 460 + 518,
> + .target_residency = 1100,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .enter = omap4_enter_idle,
> + .name = "C3",
> + .desc = "MPUSS OSWR",
> + },
> + },
> + .state_count = OMAP4_NUM_STATES,
I think you can drop OMAP4_NUM_STATES here, and just use:
.state_count = ARRAY_SIZE(omap4_idle_driver.states),
Then drop OMAP4_NUM_STATES all together in patch 3.
Kevin
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 04/17][V2] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
Daniel Lezcano writes:
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> Reviewed-by: Santosh Shilimkar
Missing changelog.
Kevin
> ---
> arch/arm/mach-omap2/cpuidle44xx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index cdd7932..fb0f76e 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -33,7 +33,7 @@ struct omap4_idle_statedata {
>
> #define OMAP4_NUM_STATES 3
>
> -struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
> +static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
> static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
>
> /**
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 07/17][V2] ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time
Daniel Lezcano writes:
> We initialized it at compile time, no need to do that at boot
> time.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> Reviewed-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
> 1 files changed, 1 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index b82f9fe..b0dd220 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -33,7 +33,7 @@ struct omap4_idle_statedata {
>
> #define OMAP4_NUM_STATES 3
>
> -static struct omap4_idle_statedata omap4_idle_data[] = {
> +static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES] = {
You removed OMAP4_NUM_STATES usage in patch 5, why add it back here?
Kevin
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 06/17][V2] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
Daniel Lezcano writes: > We are storing the 'omap4_idle_data' in the private data field > of the cpuidle device. As we are using this variable only in this file, > that does not really make sense. Let's use the global variable directly > instead dereferencing pointers in an idle critical loop. Did you notice a performance impact before this change? > Also, that simplfies the code. possibly, but at the expense of clean abstractions which IMO helps readability. Unless there is a real performance hit here (which I doubt), I'd prefer to leave this as is. Kevin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 11/17][V2] ARM: OMAP3: cpuidle - remove cpuidle_params_table
Daniel Lezcano writes:
> We do not longer need the ''cpuidle_params_table' array as
> we defined the states in the driver and we checked they are
> all valid.
>
> We also remove the structure definition as it is no longer used.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 28 +++-
> arch/arm/mach-omap2/pm.h | 12
> 2 files changed, 3 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 3f46e45..cdf1b8f 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -38,36 +38,14 @@
>
> #ifdef CONFIG_CPU_IDLE
>
> -/*
> - * The latencies/thresholds for various C states have
> - * to be configured from the respective board files.
> - * These are some default values (which might not provide
> - * the best power savings) used on boards which do not
> - * pass these details from the board file.
> - */
> -static struct cpuidle_params cpuidle_params_table[] = {
> - /* C1 */
> - {2 + 2, 5, 1},
> - /* C2 */
> - {10 + 10, 30, 1},
> - /* C3 */
> - {50 + 50, 300, 1},
> - /* C4 */
> - {1500 + 1800, 4000, 1},
> - /* C5 */
> - {2500 + 7500, 12000, 1},
> - /* C6 */
> - {3000 + 8500, 15000, 1},
> - /* C7 */
> - {1 + 3, 30, 1},
> -};
> -#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
> -
> /* Mach specific information to be recorded in the C-state driver_data */
> struct omap3_idle_statedata {
> u32 mpu_state;
> u32 core_state;
> };
> +
> +#define OMAP3_NUM_STATES 7
> +
Similar comment as for OMAP4. You should be able to git rid of this all
together now.
Kevin
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 10/17][V2] ARM: OMAP3: cpuidle - remove the 'valid' field
Daniel Lezcano writes:
> With the previous changes all the states are valid, except
> the last state which can be handled by decreasing the number
> of states.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 12 +++-
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 11a2c23..3f46e45 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -67,7 +67,6 @@ static struct cpuidle_params cpuidle_params_table[] = {
> struct omap3_idle_statedata {
> u32 mpu_state;
> u32 core_state;
> - u8 valid;
> };
> struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
>
> @@ -191,8 +190,7 @@ static int next_valid_state(struct cpuidle_device *dev,
> }
>
> /* Check if current state is valid */
> - if ((cx->valid) &&
> - (cx->mpu_state >= mpu_deepest_state) &&
> + if ((cx->mpu_state >= mpu_deepest_state) &&
> (cx->core_state >= core_deepest_state)) {
> return index;
> } else {
> @@ -216,8 +214,7 @@ static int next_valid_state(struct cpuidle_device *dev,
> idx--;
> for (; idx >= 0; idx--) {
> cx = cpuidle_get_statedata(&dev->states_usage[idx]);
> - if ((cx->valid) &&
> - (cx->mpu_state >= mpu_deepest_state) &&
> + if ((cx->mpu_state >= mpu_deepest_state) &&
> (cx->core_state >= core_deepest_state)) {
> next_index = idx;
> break;
> @@ -371,7 +368,6 @@ static inline struct omap3_idle_statedata
> *_fill_cstate_usage(
> struct omap3_idle_statedata *cx = &omap3_idle_data[idx];
> struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
>
> - cx->valid = cpuidle_params_table[idx].valid;
> cpuidle_set_statedata(state_usage, cx);
>
> return cx;
> @@ -399,7 +395,6 @@ int __init omap3_idle_init(void)
>
> /* C1 . MPU WFI + Core active */
> cx = _fill_cstate_usage(dev, 0);
> - cx->valid = 1; /* C1 is always valid */
> cx->mpu_state = PWRDM_POWER_ON;
> cx->core_state = PWRDM_POWER_ON;
>
> @@ -436,14 +431,13 @@ int __init omap3_idle_init(void)
>* We disable C7 state as a result.
>*/
> if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
> - cx->valid = 0;
> + drv->state_count = OMAP3_NUM_STATES - 1;
> pr_warn("%s: core off state C7 disabled due to i583\n",
> __func__);
I'm not too particular about this one, but it might be cleaner to just
remove this check all together. This errata already has a check in
next_valid_state() so strictly speaking, it's not needed here.
Kevin
> }
> cx->mpu_state = PWRDM_POWER_OFF;
> cx->core_state = PWRDM_POWER_OFF;
>
> - drv->state_count = OMAP3_NUM_STATES;
> cpuidle_register_driver(&omap3_idle_driver);
>
> if (cpuidle_register_device(dev)) {
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/17][V2] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
Daniel Lezcano writes: > This patchset makes some cleanup on these cpuidle drivers > and consolidate the code across both architecture. Thanks for this really nice cleanup. I have some comments on specific patches, but here's some general comments: Some minor comments: First, please be sure all patches have a descriptive changelog. Yes, even simple ones need changelogs. In particular, maintainers are looking for the "why" of a patch, not just the "what" or "how". Second, this series introduced a couple sparse warnings: /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:134:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:136:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Thanks, Kevin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi, Amit, On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote: > Hi Len/Rui, > > Any comment or feedback from your side about the status of this patch? > Is it merge-able or major re-work is needed? I have fixed most of the > comments in this patchset and currently working on some of the minor > comments received and will submit them shortly. > Sorry for the late response. First of all, it makes sense to me to introduce the generic cpufrq cooling implementation. But I still have some questions. I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the current passive handling in the generic thermal layer well, right? e.g. there is no tc1/tc2 on exynos4. If yes, is it possible that we can enhance the passive cooling to support the generic processor cooling? say, introduce another way to throttle the processor in thermal_zone_device_passive when tc1 and tc2 are not available? thanks, rui > Regards, > Amit Daniel > > On 19 March 2012 11:47, Amit Daniel Kachhap wrote: > > Changes since V1: > > *Moved the sensor driver to driver/thermal folder from driver/hwmon folder > > as suggested by Mark Brown and Guenter Roeck > > *Added notifier support to notify the registered drivers of any cpu cooling > > action. The driver can modify the default cooling behaviour(eg set > > different > > max clip frequency). > > *The percentage based frequency replaced with absolute clipped frequency. > > *Some more conditional checks when setting max frequency. > > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to > > THERMAL_TRIP_STATE_INSTANCE > > *Many review comments from R, Durgadoss and > > eduardo.valen...@ti.com implemented. > > *Removed cooling stats through debugfs patch > > *The V1 based can be found here, > > https://lkml.org/lkml/2012/2/22/123 > > http://lkml.org/lkml/2012/3/3/32 > > > > Changes since RFC: > > *Changed the cpu cooling registration/unregistration API's to instance based > > *Changed the STATE_ACTIVE trip type to pass correct instance id > > *Adding support to restore back the policy->max_freq after doing frequency > > clipping. > > *Moved the trip cooling stats from sysfs node to debugfs node as suggested > > by Greg KH g...@kroah.com > > *Incorporated several review comments from eduardo.valen...@ti.com > > *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd > > as discussed with Guenter Roeck and > > Donggeun Kim (https://lkml.org/lkml/2012/1/5/7) > > *Some changes according to the changes in common cpu cooling APIs > > *The RFC based patches can be found here, > > https://lkml.org/lkml/2011/12/13/186 > > https://lkml.org/lkml/2011/12/21/169 > > > > > > Brief Description: > > > > 1) The generic cooling devices code is placed inside driver/thermal/* as > > placing inside acpi folder will need un-necessary enabling of acpi code. > > This > > codes is architecture independent. > > > > 2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which > > passes > > cooling device instance number and may be helpful for cpufreq cooling > > devices > > to take the correct cooling action. This trip type avoids the temperature > > comparision check again inside the cooling handler. > > > > 3) This patchset adds generic cpu cooling low level implementation through > > frequency clipping and cpu hotplug. In future, other cpu related cooling > > devices may be added here. An ACPI version of this already exists > > (drivers/acpi/processor_thermal.c). But this will be useful for platforms > > like ARM using the generic thermal interface along with the generic cpu > > cooling devices. The cooling device registration API's return cooling device > > pointers which can be easily binded with the thermal zone trip points. > > The important APIs exposed are, > > a)struct thermal_cooling_device *cpufreq_cooling_register( > >struct freq_clip_table *tab_ptr, unsigned int tab_size, > >const struct cpumask *mask_val) > > b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) > > > > 4) Samsung exynos platform thermal implementation is done using the generic > > cpu cooling APIs and the new trip type. The temperature sensor driver > > present > > in the hwmon folder(registered as hwmon driver) is moved to thermal folder > > and registered as a thermal driver. > > > > All this patchset is based on Kernel version 3.3-rc7 > > > > A simple data/control flow diagrams is shown below, > > > > Core Linux thermal <-> Exynos thermal interface <- Temperature > > Sensor > > | | > > \|/| > > Cpufreq cooling device <--- > > > > > > Amit Daniel Kachhap (6): > > thermal: Add a new trip type to use cooling device instance number > > thermal: Add generic cpufreq cooling implementation > > thermal: Add generic cpuhotplug cooling implementation > > hwmon: exynos4: Move therma
