Re: Changing default root file system to btrfs
On 4 August 2011 15:37, David Gilbert david.gilb...@linaro.org wrote: On 4 August 2011 15:28, James Tunnicliffe james.tunnicli...@linaro.org wrote: On 4 August 2011 14:56, David Gilbert david.gilb...@linaro.org wrote: On 4 August 2011 14:52, James Tunnicliffe james.tunnicli...@linaro.org 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? I haven't used dd in a while for this, so I don't have a dd line as such. I did just try the line you gave and it ran at the highest speed that flashbench showed that my SD card could provide, so thanks for that! Not sure what I did differently last time... no matter, this will speed up testing a lot. I am slightly concerned having searched around about using ext* on flash - it sounds like ext2 and ext3 at least may be good at wearing out SD cards. Using dd is good for avoiding the file attribute and journal updates that would happen during the initial copy of the root file system to an SD card, so if I am using ext3 it will be my preferred way of getting a card ready. Unfortunately a lot of what I have read should have [citation needed] attached to it. One post that at least seemed logical was: http://talk.maemo.org/showthread.php?t=16873 pauljohn32 In the Fedora linux list, we had a long thread about ext3 on Sd cards. Consensus was that it is bad to do this because it will use up the finite number of writes on the card. They recommend VFAT because it does not make as many separate writes when files are accessed. ext2 is expensive because it tracks so many attributes,especially atime.. ext3 is more costly because of journaling. I have done a bit of benchmarking, which involves copying the files that are in the root file system of a Nano image plus a few larger files over to the same SD card formatted with different file systems: btrfs: 0m55.181s ext3: 3m28.145s ext4: 1m20.663s ext4 no journal: 1m17.868s My guess is that not only does a fast copy keep me happy, it also keeps my SD card happy (faster probably indicates fewer read, modify, write cycles = lasts longer). It looks like we should change our default file system to ext4 so we default to a file system that we can all be confident in and those of us who want to can use btrfs. Disabling the journal may help with SD card longevity, but it doesn't seem to make much difference to speed in this case. But... I just tested two a nano images using ext4 and they didn't find the root file system. So, we are at least gated on that bug. -- James Tunnicliffe ___ 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/04/2011 12:26 PM, Vincent Guittot wrote: On 4 August 2011 09:57, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 08/03/2011 06:25 PM, Vincent Guittot wrote: Hi Daniel, On 3 August 2011 15:58, Daniel Lezcano daniel.lezc...@linaro.org 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 ? IMO, this is out of the scope of the pm-qa test suite. The test suite should check the different subsystem are correct. In our case, we should ensure two processes ran only on a single socket and was not spread on two different socket. I don't know how to do that right now, but I think this is what we should validate. What you are proposing is some kind of power management benchmark. That makes sense and would be very useful to check where is the consumption cursor. But a set of prerequisite will be needed for that: (1) the pm blocks should be validated by pm-qa (2) we have to define an userspace scenario where we set the system with a maximum power saving policy (3) run different application and collect the consumption We can imagine to have it automated, ran when there is a kernel update and plot the result like: http://www.phoronix.com/scan.php?page=articleitem=linux_mobile_uffdanum=1 - -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOO923AAoJEAKBbMCpUGYApb8H/0CnUxghj8Ad0SfBGPIZLFzH 0Y6Q+8LGchv+UDlxv9kZlj0UjVSUWFDoOI9FMopj34RQFtFzkETzJsjxJ+s1OcfM hnlPzJQCMz76gXwKWU1b5eHdKbzVv/vW7yC4kEMcBX/XpYSxnyCM6x+e9ooQf01v OgnPWFqRLTyLFv4ZF1+OC5oROwmNbCd77efMJdtDijg8Ka9dzuWKtfATOjl3tGBP iouhJxmMgw0878n7QnUkLQl/DtFFTzHLHr4FBP7HRieG9QIU87no5o8M0NMak3vh rwyLet0TeCmK9rzzVs2tFgaY+yw361tnK4fzABYdBBFNCzeyvbXS550qEUrw+7E= =Grtm -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 4/5] test_03 : check topology file presence
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- sched_mc/test_03.sh | 33 + 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 sched_mc/test_03.sh diff --git a/sched_mc/test_03.sh b/sched_mc/test_03.sh new file mode 100644 index 000..b5a9c49 --- /dev/null +++ b/sched_mc/test_03.sh @@ -0,0 +1,33 @@ +#!/bin/bash +# +# PM-QA validation test suite for the power management on ARM +# +# Copyright (C) 2011, Linaro Limited. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +# +# Contributors: +# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation) +# - initial API and implementation +# + +# URL : https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts#sched_mc_03 + +source ../include/functions.sh + +FILES=core_id core_siblings core_siblings_list physical_package_id \ +thread_siblings thread_siblings_list + +for_each_cpu check_topology_files $FILES -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 3/5] test_02 : check topology is enabled
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
include/functions.sh | 12
sched_mc/test_02.sh | 38 ++
2 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 sched_mc/test_02.sh
diff --git a/include/functions.sh b/include/functions.sh
index e01d0dc..094d877 100644
--- a/include/functions.sh
+++ b/include/functions.sh
@@ -208,6 +208,18 @@ check_sched_mc_files() {
return 0
}
+check_topology_files() {
+
+local dirpath=$CPU_PATH/$1/topology
+shift 1
+
+for i in $@; do
+ check $i exists test -f $dirpath/$i || return 1
+done
+
+return 0
+}
+
save_governors() {
governors_backup=
diff --git a/sched_mc/test_02.sh b/sched_mc/test_02.sh
new file mode 100644
index 000..36730a4
--- /dev/null
+++ b/sched_mc/test_02.sh
@@ -0,0 +1,38 @@
+#!/bin/bash
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+#
+# Contributors:
+# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation)
+# - initial API and implementation
+#
+
+# URL :
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts#sched_mc_02
+
+source ../include/functions.sh
+
+check_physical_package_id() {
+
+local package_id=$CPU_PATH/$1/topology/physical_package_id
+local val=$(cat $package_id)
+
+check topology is enabled test \$val\ != \-1\
+}
+
+for_each_cpu check_physical_package_id || exit 1
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 2/5] test_01 : test sched_mc file presence
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Makefile |3 +++
include/functions.sh | 11 +++
sched_mc/Makefile| 38 ++
sched_mc/test_01.sh | 32
4 files changed, 84 insertions(+), 0 deletions(-)
create mode 100644 sched_mc/Makefile
create mode 100644 sched_mc/test_01.sh
diff --git a/Makefile b/Makefile
index be9df5d..abc866b 100644
--- a/Makefile
+++ b/Makefile
@@ -29,8 +29,11 @@ all:
check:
@(cd utils; $(MAKE) check)
@(cd cpufreq; $(MAKE) check)
+ @(cd sched_mc; $(MAKE) check)
+
uncheck:
@(cd cpufreq; $(MAKE) uncheck)
+ @(cd sched_mc; $(MAKE) uncheck)
recheck: uncheck check
diff --git a/include/functions.sh b/include/functions.sh
index 67c356a..e01d0dc 100644
--- a/include/functions.sh
+++ b/include/functions.sh
@@ -197,6 +197,17 @@ check_cpufreq_files() {
return 0
}
+check_sched_mc_files() {
+
+local dirpath=$CPU_PATH
+
+for i in $@; do
+ check $i exists test -f $dirpath/$i || return 1
+done
+
+return 0
+}
+
save_governors() {
governors_backup=
diff --git a/sched_mc/Makefile b/sched_mc/Makefile
new file mode 100644
index 000..f52a1f4
--- /dev/null
+++ b/sched_mc/Makefile
@@ -0,0 +1,38 @@
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+#
+# Contributors:
+# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation)
+# - initial API and implementation
+#
+
+TST=$(wildcard *.sh)
+LOG=$(TST:.sh=.log)
+
+check: uncheck $(LOG)
+
+%.log: %.sh
+ @./$ 2 $@
+
+clean:
+ rm -f $(LOG)
+
+uncheck: clean
+
+recheck: uncheck check
diff --git a/sched_mc/test_01.sh b/sched_mc/test_01.sh
new file mode 100644
index 000..e0fd9aa
--- /dev/null
+++ b/sched_mc/test_01.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+#
+# Contributors:
+# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation)
+# - initial API and implementation
+#
+
+# URL :
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts#sched_mc_01
+
+source ../include/functions.sh
+
+FILES=sched_mc_power_savings
+
+check_sched_mc_files $FILES
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 1/5] fix error output to the log file
Error messages have to go to the log file Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- cpufreq/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpufreq/Makefile b/cpufreq/Makefile index 5dfc00d..f52a1f4 100644 --- a/cpufreq/Makefile +++ b/cpufreq/Makefile @@ -25,10 +25,10 @@ TST=$(wildcard *.sh) LOG=$(TST:.sh=.log) -check: $(LOG) +check: uncheck $(LOG) %.log: %.sh - @./$ + @./$ 2 $@ clean: rm -f $(LOG) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[pm-qa 5/5] test_04 : check we can change sched_mc policy
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
sched_mc/test_04.sh | 70 +++
1 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 sched_mc/test_04.sh
diff --git a/sched_mc/test_04.sh b/sched_mc/test_04.sh
new file mode 100644
index 000..4d7cfc1
--- /dev/null
+++ b/sched_mc/test_04.sh
@@ -0,0 +1,70 @@
+#!/bin/bash
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+#
+# Contributors:
+# Daniel Lezcano daniel.lezc...@linaro.org (IBM Corporation)
+# - initial API and implementation
+#
+
+# URL :
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts#sched_mc_04
+
+source ../include/functions.sh
+
+check_change() {
+local val=$1
+local path=$2
+
+echo $val $path
+}
+
+check_invalid_change() {
+
+local val=$1
+local path=$2
+
+echo $val $path
+if [ $? != 0 ]; then
+ return 0
+fi
+
+return 1
+}
+
+check_sched_mc_change() {
+
+local path=$CPU_PATH/sched_mc_power_savings
+local oldval=$(cat $path)
+
+check setting value to 0 check_change 0 $path
+check setting value to 1 check_change 1 $path
+check setting value to 2 check_change 2 $path
+check setting invalid value to 3 check_invalid_change 3 $path
+check setting invalid value to -1 check_invalid_change -1 $path
+
+echo $oldval $path
+}
+
+if [ $(id -u) != 0 ]; then
+log_skip run as non-root
+exit 0
+fi
+
+# check_sched_mc_files sched_mc_power_savings || exit 1
+check_sched_mc_change
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: sched_mc test scenario
On Fri, Aug 5, 2011 at 1:10 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2011 12:26 PM, Vincent Guittot wrote: On 4 August 2011 09:57, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 08/03/2011 06:25 PM, Vincent Guittot wrote: Hi Daniel, On 3 August 2011 15:58, Daniel Lezcano daniel.lezc...@linaro.org 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 ? IMO, this is out of the scope of the pm-qa test suite. The test suite should check the different subsystem are correct. In our case, we should ensure two processes ran only on a single socket and was not spread on two different socket. I don't know how to do that right now, but I think this is what we should validate. What you are proposing is some kind of power management benchmark. Right. Let's keep the 'functional' tests separate from the 'measurement' tests. Functional tests will catch Kconfig errors, and ensure that the feature works according to the interface we care about. PM-QA will (in the future) contain benchmark tests too that we'll use to measure how we're doing wrt power. That makes sense and would be very useful to check where is the consumption cursor. But a set of prerequisite will be needed for that: (1) the pm blocks should be validated by pm-qa (2) we have to define an userspace scenario where we set the system with a maximum power saving policy (3) run different application and collect the consumption We can imagine to have it automated, ran when there is a kernel update and plot the result like: http://www.phoronix.com/scan.php?page=articleitem=linux_mobile_uffdanum=1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v3 01/11] MFD: DA9052 MFD core module
The DA9052 is a highly integrated PMIC subsystem with supply domain flexibility to support wide range of high performance application. It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery control and other functionality. Signed-off-by: David Dajun Chen dc...@diasemi.com Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com --- Changes since v3: - Code refactored to use REGMAP API. - Add Battery resources. - da9052_set_bits() and da9052_clear_bits() replaced by da9052_reg_update(). - Add support for DA9053 PMIC Changes since v2: - Drop da9052_irqs[] table. - Move struct da9052_subdev_info[]. - Remove initialization of static member. - Care for NULL pdata init(). - Check removal of subdevices on errors. - Remove open source spi code. - Remove '_spi' from the driver name. - Move tbat_lookup table from header file. - Remove irq.h - Remove num_gpio variable from pdata --- drivers/mfd/Kconfig | 67 drivers/mfd/Makefile |7 + drivers/mfd/da9052-core.c | 404 +++ drivers/mfd/da9052-i2c.c | 137 +++ drivers/mfd/da9052-irq.c | 170 drivers/mfd/da9052-spi.c | 107 + include/linux/mfd/da9052/da9052.h | 84 include/linux/mfd/da9052/pdata.h | 42 ++ include/linux/mfd/da9052/reg.h| 783 + 9 files changed, 1801 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/da9052-core.c create mode 100644 drivers/mfd/da9052-i2c.c create mode 100644 drivers/mfd/da9052-irq.c create mode 100644 drivers/mfd/da9052-spi.c create mode 100644 include/linux/mfd/da9052/da9052.h create mode 100644 include/linux/mfd/da9052/pdata.h create mode 100644 include/linux/mfd/da9052/reg.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..f879e78 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -343,6 +343,73 @@ config PMIC_DA903X individual components like LCD backlight, voltage regulators, LEDs and battery-charger under the corresponding menus. +config PMIC_DA9052 + bool + select MFD_CORE + +config MFD_DA9052_SPI + bool Support Dialog Semiconductor DA9052 PMIC with SPI + select REGMAP_SPI + select PMIC_DA9052 + depends on SPI_MASTER=y + help + Support for the Dialog Semiconductor DA9052 PMIC + when controlled using SPI. This driver provides common support + for accessing the device, additional drivers must be enabled in + order to use the functionality of the device. + +config MFD_DA9052_I2C + bool Support Dialog Semiconductor DA9052 PMIC with I2C + select REGMAP_I2C + select PMIC_DA9052 + depends on I2C=y + help + Support for the Dialog Semiconductor DA9052 PMIC + when controlled using I2C. This driver provides common support + for accessing the device, additional drivers must be enabled in + order to use the functionality of the device. + +config MFD_DA9053_SPI + bool Support Dialog Semiconductor DA9053 PMIC with SPI + select MFD_DA9052_SPI + depends on SPI_MASTER=y + help + Support for the Dialog Semiconductor DA9053 PMIC + when controlled using SPI. This driver provides common support + for accessing the device, additional drivers must be enabled in + order to use the functionality of the device. + +config MFD_DA9053_I2C + bool Support Dialog Semiconductor DA9053 PMIC with I2C + select REGMAP_I2C + select MFD_DA9052_I2C + depends on I2C=y + help + Support for the Dialog Semiconductor DA9053 PMIC + when controlled using I2C. This driver provides common support + for accessing the device, additional drivers must be enabled in + order to use the functionality of the device. + +choice + prompt Chip Type + depends on MFD_DA9053_SPI || MFD_DA9053_I2C +config PMIC_DA9053AA + bool Support Dialog Semiconductor DA9053 AA PMIC + help + Support for Dialog semiconductor DA9053 AA PMIC. + This driver provides common support for accessing the device, + additional drivers must be enabled in order to use the + functionality of the device. +config PMIC_DA9053Bx + bool Support Dialog Semiconductor DA9053 BA/BB PMIC + help + Support for Dialog semiconductor DA9053 BA/BB PMIC. + This driver provides common support for accessing the device, + additional drivers must be enabled in order to use the + functionality of the device. + +endchoice + config PMIC_ADP5520 bool Analog Devices ADP5520/01 MFD PMIC Core Support depends on I2C=y diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index c580203..89a5837 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -67,6 +67,13 @@ endif obj-$(CONFIG_UCB1400_CORE) +=
Re: sched_mc test scenario
On 5 August 2011 13:10, Daniel Lezcano daniel.lezc...@linaro.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2011 12:26 PM, Vincent Guittot wrote: On 4 August 2011 09:57, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 08/03/2011 06:25 PM, Vincent Guittot wrote: Hi Daniel, On 3 August 2011 15:58, Daniel Lezcano daniel.lezc...@linaro.org 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 ? IMO, this is out of the scope of the pm-qa test suite. The test suite should check the different subsystem are correct. In our case, we should ensure two processes ran only on a single socket and was not spread on two different socket. I don't know how to do that right now, but I think this is what we should validate. The goal of the non regression tests are not to measure improvement and check the right migration of the processes on one socket but to ensure that the performance of the kernel is still at the right level and that we have not introduce a big regression. What you are proposing is some kind of power management benchmark. That makes sense and would be very useful to check where is the consumption cursor. But a set of prerequisite will be needed for that: (1) the pm blocks should be validated by pm-qa (2) we have to define an userspace scenario where we set the system with a maximum power saving policy (3) run different application and collect the consumption We can imagine to have it automated, ran when there is a kernel update and plot the result like: http://www.phoronix.com/scan.php?page=articleitem=linux_mobile_uffdanum=1 - -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOO923AAoJEAKBbMCpUGYApb8H/0CnUxghj8Ad0SfBGPIZLFzH 0Y6Q+8LGchv+UDlxv9kZlj0UjVSUWFDoOI9FMopj34RQFtFzkETzJsjxJ+s1OcfM hnlPzJQCMz76gXwKWU1b5eHdKbzVv/vW7yC4kEMcBX/XpYSxnyCM6x+e9ooQf01v OgnPWFqRLTyLFv4ZF1+OC5oROwmNbCd77efMJdtDijg8Ka9dzuWKtfATOjl3tGBP iouhJxmMgw0878n7QnUkLQl/DtFFTzHLHr4FBP7HRieG9QIU87no5o8M0NMak3vh rwyLet0TeCmK9rzzVs2tFgaY+yw361tnK4fzABYdBBFNCzeyvbXS550qEUrw+7E= =Grtm -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Switching to Gerrit for Android code hosting - last stage
Hello, Following today's work session preparing to switching Gerrit, everything is ready for the cutover now: First build from Gerrit repositories is finished successfully: https://android-build.linaro.org/jenkins/job/pfalcon_beagle-gerrit/4 Gerrit Web UI is migrated to the final location: http://review.android.git.linaro.org/ Gitweb is installed at http://android.git.linaro.org/gitweb Anon git access to repositories in Gerrit available via git://android.git.linaro.org/... It's too late to do the cutover now of course, so I'd like to propose to do it on Wed 10th to be sure that all folks are back from the Connect and final bits are settled. Until then, please still use existing git as before, and feel free to elaborate your Gerrit knowledge using the info at https://wiki.linaro.org/Platform/Android/Gerrit Thanks, 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: Single zImage at Linaro Connect
Deepak, Nicolas, On 07/27/2011 09:58 PM, Nicolas Pitre wrote: To everyone, and especially to those who are expected to work on this topic next week, please find below a list of tasks that needs to be investigated and/or accomplished. I'll coordinate the work and collect patches for the team. If you have comments on this, or if you know about some omissions, please feel free to provide them as a reply to this message. I'd like to know if people are particularly interested in one (or more :-)) items they would like to work on. If so please say so as well. Are you going to publish a summary of the week? For example, are there any refinements to this list in terms of additional items or approach on how to fix. Who is working each item and which ones need help? Rob Without further ado, here it is: 0) The so called single zImage project We wish to provide the ability to build as many ARM platforms as possible into a single kernel binary image. This will greatly simplify the archive packaging and maintenance effort by having only one kernel that could be built and booted on multiple ARM targets. A side effect of this is also to enforce better source code architecture even if the resulting binaries are not always supporting multiple targets. This work started a while ago. Some initial description can be found here: https://wiki.ubuntu.com/Specs/ARMSingleKernel Part of it has been implemented already, namely the runtime determined PHYS_OFFSET, the AUTO_ZRELADDR and some other items referenced below. But there is still a large amount of work remaining. 1) Removal of any dependencies on mach/*.h from generic header files To see the current culprits: $ git grep #include mach/.*.h arch/arm/include/ arch/arm/include/asm/clkdev.h:#include mach/clkdev.h arch/arm/include/asm/dma.h:#include mach/isa-dma.h arch/arm/include/asm/floppy.h:#include mach/floppy.h arch/arm/include/asm/gpio.h:#include mach/gpio.h arch/arm/include/asm/hardware/dec21285.h:#include mach/hardware.h arch/arm/include/asm/hardware/iop3xx-adma.h:#include mach/hardware.h arch/arm/include/asm/hardware/iop3xx-gpio.h:#include mach/hardware.h arch/arm/include/asm/hardware/sa.h:#include mach/bitfield.h arch/arm/include/asm/io.h:#include mach/io.h arch/arm/include/asm/irq.h:#include mach/irqs.h arch/arm/include/asm/mc146818rtc.h:#include mach/irqs.h arch/arm/include/asm/memory.h:#include mach/memory.h arch/arm/include/asm/mtd-xip.h:#include mach/mtd-xip.h arch/arm/include/asm/pci.h:#include mach/hardware.h /* for PCIBIOS_MIN_* */ arch/arm/include/asm/pgtable.h:#include mach/vmalloc.h arch/arm/include/asm/system.h:#include mach/barriers.h arch/arm/include/asm/timex.h:#include mach/timex.h arch/arm/include/asm/vga.h:#include mach/hardware.h 1.1) mach/memory.h This may contain the following defines: 1.1.1) ARM_DMA_ZONE_SIZE This can be eliminated by moving that value into struct machine_desc. The work is done already, but presented as an example for other tasks: http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/dma And as of now this is merged in mainline already for v3.1-rc1. 1.1.2) PLAT_PHYS_OFFSET Most occurrences can be eliminated. With CONFIG_ARM_PATCH_PHYS_VIRT, it is possible to determine PHYS_OFFSET at run time. Remains to remove the direct uses, mostly by mdesc-boot_params initializers. Changing boot_params into atag_offset has two effects: that makes it clearer that it is only about ATAGs and not DT, and a relative offset plays more nicely with a runtime determined PHYS_OFFSET. This work is done but not yet accepted: http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123480 1.1.3) FLUSH_BASE, FLUSH_BASE_PHYS, FLUSH_BASE_MINICACHE, UNCACHEABLE_ADDR Those are StrongARM related constants, and different for each variants. Fixing this involves making the virtual addresses constant for all variants, and hiding the differences in the physical addresses during the actual mapping. The solution is here: http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123477/force_load=t/focus=124849 1.1.4) CONSISTENT_DMA_SIZE Maybe the CMA work will make this obsolete and the consistent DMA area could be dynamically adjusted. In the mean time, the easiest solution is probably to store this in the machine_desc structure just like with ARM_DMA_ZONE_SIZE. This has not been addressed yet. 1.1.5) Other weird things Some machines have non linear memory maps or bus address translations, sparsemem, etc. Examples of that are: arch/arm/mach-realview/include/mach/memory.h arch/arm/mach-integrator/include/mach/memory.h I think solving this is out of scope for this round. Deleting arch/arm/mach-*/include/mach/memory.h can't be done universally. So a new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which machine class has its legacy
