What are the chances of a phone based developer image
Hi, Recently we have been looking at how to squeeze more performance out of our toolchain for building Firefox on Android. Mike Hommey integrated GCC 4.6 into the android NDK and has been testing performance (with mixed results http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html). I like how Linaro is doing regular arm benchmarking, ie https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07 . Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations. We are also looking at setting a developer-friendly android ROM with oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be beneficial for us to use newer kernels as we exlore options like kernel-assisted ld.so relocations, etc. That seems to similar to what Linaro provides in the evaluation ROMS. Is there any chance of Linaro providing developer-friendly "evaluation" ROMs for retail phones like the Nexus S? Thanks, Taras ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On 4 August 2011 15:28, James Tunnicliffe wrote: > On 4 August 2011 14:56, David Gilbert wrote: >> On 4 August 2011 14:52, James Tunnicliffe >> wrote: >>> I have seen poor performance when DDing to a card, which I assume is >>> because dd is not writing large aligned chunks. If we can dd the first >>> meg or so of data onto the card, then write in 4MB chunks that are all >>> 4MB aligned that should be quick (at least, if my reading of my >>> flashbench results is correct). >> >> What options to dd are you using? dd if=file of=/dev/thewholedevice bs=4096k >> should write 4MB chunks out > > My understanding is they are 4MB chunks, but not aligned to 4MB boundaries. What exactly is your dd line? Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On 4 August 2011 14:56, David Gilbert wrote: > On 4 August 2011 14:52, James Tunnicliffe > wrote: >> I have seen poor performance when DDing to a card, which I assume is >> because dd is not writing large aligned chunks. If we can dd the first >> meg or so of data onto the card, then write in 4MB chunks that are all >> 4MB aligned that should be quick (at least, if my reading of my >> flashbench results is correct). > > What options to dd are you using? dd if=file of=/dev/thewholedevice bs=4096k > should write 4MB chunks out My understanding is they are 4MB chunks, but not aligned to 4MB boundaries. -- James Tunnicliffe ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On 4 August 2011 14:52, James Tunnicliffe wrote: > I have seen poor performance when DDing to a card, which I assume is > because dd is not writing large aligned chunks. If we can dd the first > meg or so of data onto the card, then write in 4MB chunks that are all > 4MB aligned that should be quick (at least, if my reading of my > flashbench results is correct). What options to dd are you using? dd if=file of=/dev/thewholedevice bs=4096k should write 4MB chunks out Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On 4 August 2011 13:07, Daniel Lezcano wrote: > IMHO it is not stable enough and I am not sure it is worth having such > filesystem as it is mainly used for snapshotting. The last time I played > with it, the FS was quickly corrupted but I don't have to complain > because the kernel configuration help was explicit enough :) > > "Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. > You should say N here unless you are interested in > testing Btrfs with non-critical data." That description is, as far as I can tell, out of date. https://help.ubuntu.com/community/btrfs#Stability I haven't had any problems with my testing, which includes pulling the power on the board I am using, but I haven't torture tested it. Paul: It has been file system option for Ubuntu since 10.10. I have seen poor performance when DDing to a card, which I assume is because dd is not writing large aligned chunks. If we can dd the first meg or so of data onto the card, then write in 4MB chunks that are all 4MB aligned that should be quick (at least, if my reading of my flashbench results is correct). -- James Tunnicliffe ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
> As I understand it, btrfs is considered OK for file systems running on > systems that don't suffer from power failure, so for writing an image > and testing it this should be fine. > > So, what do people think about switching? I too would be considered about filesystem integrity given the number of times I'm forced to yank the power cord on my board. What speed class card are you using though? I tried a low-end one at first and quickly decided the extra US$5 for a class 6 card (San Disk Extreme) paid back the next time I used l-m-c. -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
Hi James On Thu, Aug 4, 2011 at 6:46 AM, James Tunnicliffe wrote: > Hi, > > Our current default root file system, ext3, is proving to be a > bottleneck for SD card performance. Not only does it take a long time > to format the partitions, but it also takes a long time to write to. > This slows down creating images on SD cards a lot. I just did a very > simple experiment running linaro-media-create, writing an Ubuntu > Desktop image to an SD card: > > As I understand it, btrfs is considered OK for file systems running on > systems that don't suffer from power failure, so for writing an image > and testing it this should be fine. > > So, what do people think about switching? There's no need to switch. btrfs vs ext* is simply a choice to be made at the time you call linaro-media-create. There's nothing stopping you from using btrfs if that's what you want to do with all the caveats etc that have been stated by others. -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On Thu, 4 Aug 2011 12:46:58 +0100 James Tunnicliffe wrote: > Hi, > > Our current default root file system, ext3, is proving to be a > bottleneck for SD card performance. Not only does it take a long time > to format the partitions, but it also takes a long time to write to. > This slows down creating images on SD cards a lot. I just did a very > simple experiment running linaro-media-create, writing an Ubuntu > Desktop image to an SD card: > > ext3: > 139.85user 35.27system 44:03.58elapsed 6%CPU (0avgtext+0avgdata > 107360maxresident)k > 2876115inputs+7048200outputs (958major+1677659minor)pagefaults 0swaps > > btrfs: > 146.52user 34.48system 19:57.16elapsed 15%CPU (0avgtext+0avgdata > 107408maxresident)k > 4417521inputs+6542992outputs (138major+1779874minor)pagefaults 0swaps > > As I understand it, btrfs is considered OK for file systems running on > systems that don't suffer from power failure, so for writing an image > and testing it this should be fine. > > So, what do people think about switching? There were few concerns already expressed, so I just add: is btrfs supported out of the box by kernels in last ~3 Ubuntu releases? Because if one can't look at/change contents produced on an SD card, that undermines purpose of evaluation builds much. Those ext3 vs btrfs results are very vivid though, but I wonder if it makes sense to try to tweak ext3 & mount options. And after all, we could prepare partition image(s) on the local HDD and dd them to a card... -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch 01/11] MFD: DA9052 Code refactored to use regmap
On Thu, Aug 04, 2011 at 06:15:02PM +0530, ashishj3 wrote: > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -350,6 +350,7 @@ config MFD_DA9052_SPI > bool "Support Dialog Semiconductor DA9052 PMIC with SPI" > select MFD_CORE > select PMIC_DA9052 > + select REGMAP_SPI > depends on SPI_MASTER=y > help > Support for the Dialog Semiconductor DA9052 PMIC This is an incremental patch against a driver that's not yet been merged. As has been pointed out before you should send the complete patch when submitting drivers that have not yet been merged. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch v2 04/11]Power: DA9052 battery driver
On Fri, 2011-07-22 at 18:22 +0530, ashishj3 wrote: > Driver for DA9052 battery charger. This driver depends on DA9052 MFD core > dirver > for definitions and methods. > > Signed-off-by: David Dajun Chen > Signed-off-by: Ashish Jangam > --- > Changes since v2 > - Correct code styling for inline functions > - Remove averaging algorithm > - Set use_for_apm thru board specific parameter > --- Any comments on this patch? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Patch 01/11] MFD: DA9052 Code refactored to use regmap
DA9052 MFD Code is refactored to add remap support in the DA9052.
Recent changes to DA9052 battery module also required certain components
to be added in this patch. Also set bits and clear bits are removed
and instead da9052_reg_update() will be used in future.
Signed-off-by: David Dajun Chen
Signed-off-by: Ashish Jangam
---
drivers/mfd/Kconfig |2 +
drivers/mfd/da9052-core.c | 243
drivers/mfd/da9052-i2c.c | 73 +++
drivers/mfd/da9052-spi.c | 55 +++--
include/linux/mfd/da9052/da9052.h | 13 +--
include/linux/mfd/da9052/pdata.h |3 +-
include/linux/mfd/da9052/reg.h|2 +
7 files changed, 98 insertions(+), 293 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e0de26a..9a77294 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -350,6 +350,7 @@ config MFD_DA9052_SPI
bool "Support Dialog Semiconductor DA9052 PMIC with SPI"
select MFD_CORE
select PMIC_DA9052
+ select REGMAP_SPI
depends on SPI_MASTER=y
help
Support for the Dialog Semiconductor DA9052 PMIC
@@ -361,6 +362,7 @@ config MFD_DA9052_I2C
bool "Support Dialog Semiconductor DA9052 PMIC with I2C"
select MFD_CORE
select PMIC_DA9052
+ select REGMAP_I2C
depends on I2C=y
help
Support for the Dialog Semiconductor DA9052 PMIC
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index f572ad0..271fe5b 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -23,6 +23,10 @@
#include
#include
+#define DA9052_IRQ_DCIN0
+#define DA9052_IRQ_VBUS1
+#define DA9052_IRQ_DCINREM 2
+#define DA9052_IRQ_VBUSREM 3
#define DA9052_IRQ_ALARM 5
#define DA9052_IRQ_NONKEY 8
#define DA9052_IRQ_CHGEND 11
@@ -176,243 +180,80 @@ EXPORT_SYMBOL_GPL(da9052_adc_temperature_read);
int da9052_reg_read(struct da9052 *da9052, unsigned char reg)
{
- unsigned char val;
- int ret;
+ int val, ret;
if (reg > DA9052_MAX_REG_CNT) {
dev_err(da9052->dev, "invalid reg %x\n", reg);
return -EINVAL;
}
- mutex_lock(&da9052->io_lock);
-
- if (da9052->read_dev == NULL) {
- ret = -ENODEV;
- goto err;
- }
-
- ret = da9052->read_dev(da9052, reg, 1, &val);
- if (ret)
- goto err;
+ #ifdef CONFIG_MFD_DA9052_SPI
+ reg = (reg << 1) | 1;
+ #endif
- mutex_unlock(&da9052->io_lock);
+ ret = regmap_read(da9052->regmap, reg, &val);
+ if (ret < 0)
+ return ret;
return val;
-
-err:
- mutex_unlock(&da9052->io_lock);
- return ret;
}
EXPORT_SYMBOL_GPL(da9052_reg_read);
int da9052_reg_write(struct da9052 *da9052, unsigned char reg,
unsigned char val)
{
- int ret;
-
if (reg > DA9052_MAX_REG_CNT) {
dev_err(da9052->dev, "invalid reg %x\n", reg);
return -EINVAL;
}
- mutex_lock(&da9052->io_lock);
+ #ifdef CONFIG_MFD_DA9052_SPI
+ reg <<= 1;
+ #endif
- if (da9052->write_dev == NULL) {
- ret = -ENODEV;
- goto err;
- }
-
- ret = da9052->write_dev(da9052, reg, 1, &val);
- if (ret < 0)
- goto err;
-
- mutex_unlock(&da9052->io_lock);
-
- return 0;
-
-err:
- mutex_unlock(&da9052->io_lock);
- return ret;
+ return regmap_write(da9052->regmap, reg, val);
}
EXPORT_SYMBOL_GPL(da9052_reg_write);
int da9052_group_read(struct da9052 *da9052, unsigned char reg,
unsigned reg_cnt, unsigned char *val)
{
- int ret;
-
if (reg > DA9052_MAX_REG_CNT) {
dev_err(da9052->dev, "invalid reg %x\n", reg);
return -EINVAL;
}
- mutex_lock(&da9052->io_lock);
-
- if (da9052->read_dev == NULL) {
- ret = -ENODEV;
- goto err;
- }
-
- ret = da9052->read_dev(da9052, reg, reg_cnt, val);
- if (ret < 0)
- goto err;
+ #ifdef CONFIG_MFD_DA9052_SPI
+ reg = (reg << 1) | 1;
+ #endif
- mutex_unlock(&da9052->io_lock);
-
- return 0;
-
-err:
- mutex_unlock(&da9052->io_lock);
- return ret;
+ return regmap_bulk_read(da9052->regmap, reg, val, reg_cnt);
}
EXPORT_SYMBOL_GPL(da9052_group_read);
int da9052_group_write(struct da9052 *da9052, unsigned char reg,
unsigned reg_cnt, unsigned char *val)
{
- int ret;
-
- if (reg > DA9052_MAX_REG_CNT) {
- dev_err(da9052->dev, "invalid reg %x\n", reg);
- return -EINVAL;
- }
-
- mutex_lock(&da9052->io_lock);
-
- if (da9052->write_dev == NULL) {
- ret = -ENODEV;
-
Re: Changing default root file system to btrfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2011 01:46 PM, James Tunnicliffe wrote: > Hi, > > Our current default root file system, ext3, is proving to be a > bottleneck for SD card performance. Not only does it take a long time > to format the partitions, but it also takes a long time to write to. > This slows down creating images on SD cards a lot. I just did a very > simple experiment running linaro-media-create, writing an Ubuntu > Desktop image to an SD card: > > ext3: > 139.85user 35.27system 44:03.58elapsed 6%CPU (0avgtext+0avgdata > 107360maxresident)k > 2876115inputs+7048200outputs (958major+1677659minor)pagefaults 0swaps > > btrfs: > 146.52user 34.48system 19:57.16elapsed 15%CPU (0avgtext+0avgdata > 107408maxresident)k > 4417521inputs+6542992outputs (138major+1779874minor)pagefaults 0swaps > > As I understand it, btrfs is considered OK for file systems running on > systems that don't suffer from power failure, so for writing an image > and testing it this should be fine. > > So, what do people think about switching? IMHO it is not stable enough and I am not sure it is worth having such filesystem as it is mainly used for snapshotting. The last time I played with it, the FS was quickly corrupted but I don't have to complain because the kernel configuration help was explicit enough :) "Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOOot+AAoJEAKBbMCpUGYAYB4H/13CMOSsPFoxypWFcV9UfqzE Ni7WTmiiWDRWlcZVUwGIInwJVs/DIb5liVqT+qn7zlQ0kp0++lTFk3VEl28DoKej q1yvWwews9t8RddFYQrgb4LSzEJuQzDeTZyT1tIexSNihJMLa+nUvhsEwwrPlFCn hPF5pBeFze2uXOrvJ0e/tSlBQ7vIdWoXnz4CZJRH13HvaqHjD0c7qq1/hNQv2mWi qel49BuDI4uucODuEKOw3eof1YLAh/l6F29sqpBKzRWEmRMBgpnGpAbzjawMtpRg 4tyGmFOX4A3zSODMr2c2+PFEZiovzJUaKV0vPew+8GoIyE/cOUzx1amJxvMMMDw= =5D2R -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root file system to btrfs
On 4 August 2011 12:46, James Tunnicliffe wrote: > Hi, > > Our current default root file system, ext3, is proving to be a > bottleneck for SD card performance. Not only does it take a long time > to format the partitions, but it also takes a long time to write to. > This slows down creating images on SD cards a lot. I just did a very > simple experiment running linaro-media-create, writing an Ubuntu > Desktop image to an SD card: > > ext3: > 139.85user 35.27system 44:03.58elapsed 6%CPU (0avgtext+0avgdata > 107360maxresident)k > 2876115inputs+7048200outputs (958major+1677659minor)pagefaults 0swaps > > btrfs: > 146.52user 34.48system 19:57.16elapsed 15%CPU (0avgtext+0avgdata > 107408maxresident)k > 4417521inputs+6542992outputs (138major+1779874minor)pagefaults 0swaps What's dpkg like these days on btrfs - it used to be awfully slow. Some comparisons from the installed running system would really be needed. > As I understand it, btrfs is considered OK for file systems running on > systems that don't suffer from power failure, so for writing an image > and testing it this should be fine. It doesn't sound like the description of development systems though where people will crash them and reset them and generally pull the plug on them. > So, what do people think about switching? To be honest I trust ext* (it's never lost me a byte in many years of use) and btr feels a bit new to me; but that's a personal feeling. Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ADB/Android Screencast
Hello, On Wed, 3 Aug 2011 16:50:19 +0530 Sachin Kamat wrote: [] > > I assume most people have used ADB and had to create a udev rule to > > set permissions on their board. We have a wiki page > > (https://wiki.linaro.org/Platform/Android/ConfigureAndUseAdbOnPanda) > > with the rules for Panda/TI and Snowball/ST-Ericsson, but it would > > be nice if some of you could add the rules for the other > > boards/vendors too so everything's in one place. > > > > Updated udev rules for Origen (Samsung Exynos4 based) board on the > wiki. Thanks. So, consequently it's not ConfigureAndUseAdbOnPanda any longer, but https://wiki.linaro.org/Platform/Android/ConfigureAndUseAdb I also linked to it from https://wiki.linaro.org/Platform/Android/ImageInstallation#After_Installation (the official Linaro Android images install guide) which talked about that issue (and also contains more ADB tips). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Changing default root file system to btrfs
Hi, Our current default root file system, ext3, is proving to be a bottleneck for SD card performance. Not only does it take a long time to format the partitions, but it also takes a long time to write to. This slows down creating images on SD cards a lot. I just did a very simple experiment running linaro-media-create, writing an Ubuntu Desktop image to an SD card: ext3: 139.85user 35.27system 44:03.58elapsed 6%CPU (0avgtext+0avgdata 107360maxresident)k 2876115inputs+7048200outputs (958major+1677659minor)pagefaults 0swaps btrfs: 146.52user 34.48system 19:57.16elapsed 15%CPU (0avgtext+0avgdata 107408maxresident)k 4417521inputs+6542992outputs (138major+1779874minor)pagefaults 0swaps As I understand it, btrfs is considered OK for file systems running on systems that don't suffer from power failure, so for writing an image and testing it this should be fine. So, what do people think about switching? -- James Tunnicliffe ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ADB/Android Screencast
On 3 August 2011 23:06, Alexander Sack wrote:
> On Wed, Aug 3, 2011 at 1:20 PM, Sachin Kamat
> wrote:
> >
> >
> > On 3 August 2011 14:31, Fathi Boudra wrote:
> >>
> >> forward to linaro-dev ml
> >>
> >> -- Forwarded message --
> >> From: Frans Gifford
> >> Date: 3 August 2011 11:55
> >> Subject: ADB/Android Screencast
> >>
> >> Hi all,
> >>
> >> I assume most people have used ADB and had to create a udev rule to
> >> set permissions on their board. We have a wiki page
> >> (https://wiki.linaro.org/Platform/Android/ConfigureAndUseAdbOnPanda)
> >> with the rules for Panda/TI and Snowball/ST-Ericsson, but it would be
> >> nice if some of you could add the rules for the other boards/vendors
> >> too so everything's in one place.
> >
> > Updated udev rules for Origen (Samsung Exynos4 based) board on the wiki.
>
> IIRC I always see complains about SYSFS (or another iteam, cant
> remember) of those rules being deprecated and that we should use
> ATTR{S} instead.
>
> Can we update the entries to match the modern syntax please?
Yup.. That's updated to use ATTR{s} syntax. Thanks for the suggestion.
> Once they
> are updated, please validate that they work and let me know. I will
> make sure we will get them into ubuntu and - if possible - upstream
> udev rules DB.
>
> --
>
> - Alexander
>
--
With warm regards,
Sachin
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH] SMDKV310: MMC_SPL: Fix building when using "make O="
On 03/06/2011 06:07, Chander Kashyap wrote: Fixes dependency build error with "make O=" option. "make O=" option is used to specify output directory. Signed-off-by: Chander Kashyap --- mmc_spl/board/samsung/smdkv310/Makefile | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: sched_mc test scenario
On 4 August 2011 09:57, Daniel Lezcano wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/03/2011 06:25 PM, Vincent Guittot wrote: >> Hi Daniel, >> >> On 3 August 2011 15:58, Daniel Lezcano wrote: > > [ ... ] > >>> it sounds good for me. > > Ok, cool. Thanks. > >> Concerning the functional tests, I need some hints :) >> >> On the architecture we have, that will be difficult to verify sched_mc >> works as expected. >> If I understood correctly, in order to test that, we should have a >> dual Cortex-A9 to check a program with two processes eating a lot of >> cpu cycles will be bounded in the same socket_id when >> sched_mc_power_savings=2. >> The other processor staying idle or not running any of these >> processes, right ? AFAIK, there is no such hardware, no ? >> >>> you could integrate a non regression test which check that performance >>> results in both sched_mc_power_savings=0 and sched_mc_power_savings=2 >>> . I have one which uses cyclictest and sysbench. > > Can you elaborate a bit ? Do you mean, we should run the test and > compare the result to some hardcoded values (taking account the > hysteresis of course) ? > yes we should compare the results with some hard coded values or a reference test results. I don't know if it's possible to use the result of a previous tests sequence in order to make some comparisons et set a test has passed or failed ? >>> Then, you're right >>> that we must wait a bit before adding some functional tests which test >>> that sched_mc is working as expected (from a power saving point of >>> view) with sched_mc_power_savings=2 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOOl7mAAoJEAKBbMCpUGYATdMIAJ8lkSd5Rxw4iU/ta2GKMCnc > THA2/XdaS/lNXtdCIiQX1u1bIz9YGcRwQhnPA3oFJoDbRs/67EroNhoW8o7gwzk6 > F8AFhbqcjj3YdykJ5k3rxsxdZLnUnprANxc6PTujs/Xj9qKekZ/G0SPfACmfL2aG > oTSHXAQGBl8Pb0vojGOfLDmhOAM88l13Q9vnT2gq6zYbhfSgybGnuCaUQl+DZlCh > xiXFaDgFMVMfaw2XeJQsvlgo2MnxWxo86oMZFICgF01hhCeWc9U6GNtQB0OaaQON > 8UnP04DVCjkXn76F6zua6qVSRrw/GHklXYdKdIEAGlpFEElmhjhwRSUH6Z44/04= > =BuHj > -END PGP SIGNATURE- > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Running a short android-build - LAVA CI cycle
Hello, When testing Android-build to LAVA integration (not the builds themselves), it's sometime beneficial to have quick build cycle which build something (just anything) without error and submits that to LAVA, to avoid ~1hr wait for the normal build. One way to achieve that is to add "MAKE_TARGETS=userdatatarball" to the build config, as exemplified with https://android-build.linaro.org/builds/~pfalcon/lava-test/ . Build then takes ~12mins, lower-bounded by repo checkout time. Of course, that won't produce complete Android build, so validation in LAVA will fail. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: sched_mc test scenario
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 06:25 PM, Vincent Guittot wrote: > Hi Daniel, > > On 3 August 2011 15:58, Daniel Lezcano wrote: [ ... ] >> it sounds good for me. Ok, cool. Thanks. > Concerning the functional tests, I need some hints :) > > On the architecture we have, that will be difficult to verify sched_mc > works as expected. > If I understood correctly, in order to test that, we should have a > dual Cortex-A9 to check a program with two processes eating a lot of > cpu cycles will be bounded in the same socket_id when > sched_mc_power_savings=2. > The other processor staying idle or not running any of these > processes, right ? AFAIK, there is no such hardware, no ? > >> you could integrate a non regression test which check that performance >> results in both sched_mc_power_savings=0 and sched_mc_power_savings=2 >> . I have one which uses cyclictest and sysbench. Can you elaborate a bit ? Do you mean, we should run the test and compare the result to some hardcoded values (taking account the hysteresis of course) ? >> Then, you're right >> that we must wait a bit before adding some functional tests which test >> that sched_mc is working as expected (from a power saving point of >> view) with sched_mc_power_savings=2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOOl7mAAoJEAKBbMCpUGYATdMIAJ8lkSd5Rxw4iU/ta2GKMCnc THA2/XdaS/lNXtdCIiQX1u1bIz9YGcRwQhnPA3oFJoDbRs/67EroNhoW8o7gwzk6 F8AFhbqcjj3YdykJ5k3rxsxdZLnUnprANxc6PTujs/Xj9qKekZ/G0SPfACmfL2aG oTSHXAQGBl8Pb0vojGOfLDmhOAM88l13Q9vnT2gq6zYbhfSgybGnuCaUQl+DZlCh xiXFaDgFMVMfaw2XeJQsvlgo2MnxWxo86oMZFICgF01hhCeWc9U6GNtQB0OaaQON 8UnP04DVCjkXn76F6zua6qVSRrw/GHklXYdKdIEAGlpFEElmhjhwRSUH6Z44/04= =BuHj -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
