Re: [PATCH v13] Regulator: Add Anatop regulator driver
(2012年03月22日 13:24), Shawn Guo wrote: On Wed, Mar 14, 2012 at 10:29:12AM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is an integrated regulator inside i.MX6 SoC. There are 3 digital regulators which controls PU, CORE (ARM), and SOC. And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB). This patch adds the Anatop regulator driver. Signed-off-by: Nancy Chen nancy.c...@freescale.com Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org Acked-by: Shawn Guo shawn@linaro.org Reviewed-by: Axel Lin axel@gmail.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Liam Girdwood l...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- drivers/regulator/Kconfig|8 + drivers/regulator/Makefile |1 + drivers/regulator/anatop-regulator.c | 241 ++ 3 files changed, 250 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/anatop-regulator.c I just noticed that the binding document below got lost since v11 of the series. Documentation/devicetree/bindings/regulator/anatop-regulator.txt It got lost by mistaken or you dropped it for some reason? Ouch. I'll prepare a separate patch to add back the documentation. Sorry, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v13] Regulator: Add Anatop regulator driver
On Thu, Mar 22, 2012 at 02:49:36PM +0800, Ying-Chun Liu (PaulLiu) wrote:
...
Ouch. I'll prepare a separate patch to add back the documentation.
I just gave a quick testing on the driver with the dts change you
posted on imx6. There is some little problem we may need to address.
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-vddpu@140
vddpu: 725 -- 1300 mV at 1100 mV
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-vddcore@140
cpu: 725 -- 1300 mV at 1100 mV
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-vddsoc@140
vddsoc: 725 -- 1300 mV at 1100 mV
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-2p5@130
vdd2p5: 2000 -- 2775 mV at 2400 mV
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-1p1@110
vdd1p1: 800 -- 1400 mV at 1100 mV
prom_parse: Bad cell count for
/soc/aips-bus@0200/anatop@020c8000/regulator-3p0@120
vdd3p0: 2800 -- 3150 mV at 3000 mV
The DT core function __of_translate_address will give some annoying
error messages. We call of_platform_populate from anatop mfd driver
to populate regulator device, and during the call, DT core tries to
translate reg property to address resource, and will complain if
!(#size-cells 0).
To fix that, we may want to rename reg property to something else,
e.g. anatop-reg-offset. I tested the following changes removed the
error messages above.
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 56d3c16..65bad45 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -346,16 +346,14 @@
compatible = fsl,imx6q-anatop;
reg = 0x020c8000 0x1000;
interrupts = 0 49 0x04 0 54 0x04 0 127 0x04;
- #address-cells = 1;
- #size-cells = 0;
- regulator-vddpu@140 {
+ regulator-vddpu {
compatible = fsl,anatop-regulator;
regulator-name = vddpu;
regulator-min-microvolt = 725000;
regulator-max-microvolt = 130;
regulator-always-on;
- reg = 0x140;
+ anatop-reg-offset = 0x140;
anatop-vol-bit-shift = 9;
anatop-vol-bit-width = 5;
anatop-min-bit-val = 1;
@@ -363,13 +361,13 @@
anatop-max-voltage = 130;
};
- regulator-vddcore@140 {
+ regulator-vddcore {
compatible = fsl,anatop-regulator;
regulator-name = cpu;
regulator-min-microvolt = 725000;
regulator-max-microvolt = 130;
regulator-always-on;
- reg = 0x140;
+ anatop-reg-offset = 0x140;
anatop-vol-bit-shift = 0;
anatop-vol-bit-width = 5;
anatop-min-bit-val = 1;
@@ -377,13 +375,13 @@
anatop-max-voltage = 130;
};
- regulator-vddsoc@140 {
+ regulator-vddsoc {
compatible = fsl,anatop-regulator;
regulator-name = vddsoc;
regulator-min-microvolt = 725000;
regulator-max-microvolt = 130;
regulator-always-on;
- reg = 0x140;
+ anatop-reg-offset = 0x140;
anatop-vol-bit-shift = 18;
anatop-vol-bit-width = 5;
anatop-min-bit-val = 1;
@@ -391,13 +389,13 @@
anatop-max-voltage = 130;
};
- regulator-2p5@130 {
+ regulator-2p5 {
compatible = fsl,anatop-regulator;
regulator-name = vdd2p5;
regulator-min-microvolt = 200;
Re: [PATCH] ARM: dts: imx6q: add anatop regulators
On Tue, Mar 20, 2012 at 11:28:59AM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Add anatop regulators to imx6q.dtsi for all imx6q platforms.
I would expect all those regulator device nodes be sorted by
register offset, and for the devices sharing the same register they
can be sorted by anatop-vol-bit-shift.
I'm looking at the IMX6DQRM Rev. C, and commenting the differences
I'm seeing from the document below.
Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org
Signed-off-by: Richard Zhao richard.z...@linaro.org
Cc: Shawn Guo shawn@linaro.org
---
arch/arm/boot/dts/imx6q.dtsi | 86
++
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 263e8f3..dd41514 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -346,6 +346,92 @@
compatible = fsl,imx6q-anatop;
reg = 0x020c8000 0x1000;
interrupts = 0 49 0x04 0 54 0x04 0 127 0x04;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ regulator-vddpu@140 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = vddpu;
+ regulator-min-microvolt = 725000;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ reg = 0x140;
+ anatop-vol-bit-shift = 9;
+ anatop-vol-bit-width = 5;
+ anatop-min-bit-val = 1;
+ anatop-min-voltage = 725000;
+ anatop-max-voltage = 130;
1.450V
+ };
+
+ regulator-vddcore@140 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = cpu;
+ regulator-min-microvolt = 725000;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ reg = 0x140;
+ anatop-vol-bit-shift = 0;
+ anatop-vol-bit-width = 5;
+ anatop-min-bit-val = 1;
+ anatop-min-voltage = 725000;
+ anatop-max-voltage = 130;
Ditto
+ };
+
+ regulator-vddsoc@140 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = vddsoc;
+ regulator-min-microvolt = 725000;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ reg = 0x140;
+ anatop-vol-bit-shift = 18;
+ anatop-vol-bit-width = 5;
+ anatop-min-bit-val = 1;
+ anatop-min-voltage = 725000;
+ anatop-max-voltage = 130;
Ditto
+ };
+
+ regulator-2p5@130 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = vdd2p5;
+ regulator-min-microvolt = 200;
+ regulator-max-microvolt = 2775000;
+ regulator-always-on;
+ reg = 0x130;
+ anatop-vol-bit-shift = 8;
+ anatop-vol-bit-width = 5;
+ anatop-min-bit-val = 0;
+ anatop-min-voltage = 200;
+ anatop-max-voltage = 2775000;
2.75V
+ };
+
+ regulator-1p1@110 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = vdd1p1;
+ regulator-min-microvolt = 80;
+ regulator-max-microvolt = 140;
+ regulator-always-on;
+ reg = 0x110;
Re: Gmail corrupting spaces in plain-text mail?
On 21 March 2012 18:20, Amber Graner amber.gra...@linaro.org wrote: I spoke to the Google guys about this at Connect, they said they were aware and working on a fix, but that's about all I know at the moment. As paying customers is there a channel we can use to raise the issue? Riku ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
v.l.o
Hi all, I got some bad news last night. Our ISP told me there would be a delay in getting our service up and running in the new offices. I spoke to them this morning and they're telling me that it will *probably* be Wednesday before we get connectivity, but we will know more on Monday. As a consequence I am putting v.l.o back online and delaying the move. My intention is to take it offline again on Thursday of next week and move on Friday. Obviously this plan may be fluid based on the news we get on Monday. I will obviously keep you all posted. Many apologies for the delay and thanks for your patience, Dave Dave Pigott Validation Engineer T: +44 1223 45 00 24 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: davinci: Fix for cpuidle consolidation changes
applied. thanks, Len Brown, Intel Open Source Technology Center ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] thermal: Fix for setting the thermal zone mode to enable/disable
applied. thanks, Len Brown, Intel Open Source Technology Center ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
How to install OpenCV in Linaro Android on Pandaboard
Hi, I'm doing a project using OpenCV 2.3.1 and I want to embedded this on a pandaboard. So I'm looking for someone who can help me to instal opencv on Pandabord using Linaro Android 11.11 . If you have some link or if you can advise me I would appreciate. Thanks in advance. Best Regards ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] rtc: add support for Freescale SNVS RTC
On Mon, Mar 19, 2012 at 09:04:29PM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org This adds an RTC driver for the Low Power (LP) section of SNVS. It hooks into the /dev/rtc interface and supports ioctl to complete RTC features. This driver supports device tree bindings. Then, you need to have a document in Documentation/devicetree/bindings. It only uses the RTC hw in non-secure mode. Signed-off-by: Anish Trivedi an...@freescale.com Signed-off-by: Eric Miao eric.m...@linaro.org Signed-off-by: Anson Huang b20...@freescale.com Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org Cc: Alessandro Zummo a.zu...@towertech.it Cc: Shawn Guo shawn@linaro.org --- drivers/rtc/Kconfig| 11 + drivers/rtc/Makefile |1 + drivers/rtc/rtc-snvs.c | 737 3 files changed, 749 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-snvs.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 3a125b8..d58f4b7 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -634,6 +634,17 @@ config RTC_MXC This driver can also be built as a module, if so, the module will be called rtc-mxc. +config RTC_DRV_SNVS + tristate Freescale SNVS Real Time Clock + depends on ARCH_MXC + depends on RTC_CLASS I'm not sure this is really necessary, since this config is included in if RTC_CLASS. + help +If you say yes here you get support for the Freescale SNVS +Low Power (LP) RTC module. + +This driver can also be built as a module, if so, the module +will be called rtc-snvs. + config RTC_DRV_BQ4802 tristate TI BQ4802 help diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 6e69823..8b30686 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -93,6 +93,7 @@ obj-$(CONFIG_RTC_DRV_S35390A) += rtc-s35390a.o obj-$(CONFIG_RTC_DRV_S3C)+= rtc-s3c.o obj-$(CONFIG_RTC_DRV_SA1100) += rtc-sa1100.o obj-$(CONFIG_RTC_DRV_SH) += rtc-sh.o +obj-$(CONFIG_RTC_DRV_SNVS) += rtc-snvs.o obj-$(CONFIG_RTC_DRV_SPEAR) += rtc-spear.o obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c new file mode 100644 index 000..49ac8a5 --- /dev/null +++ b/drivers/rtc/rtc-snvs.c @@ -0,0 +1,737 @@ +/* + * Copyright (C) 2011 Freescale Semiconductor, Inc. + */ + +/* + * 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. + */ +/* + * Implementation based on rtc-ds1553.c + */ + +/*! I'm not sure /*! is the format for kernel-doc. Please take a look at Documentation/kernel-doc-nano-HOWTO.txt. + * @defgroup RTC Real Time Clock (RTC) Driver + */ +/*! + * @file rtc-snvs.c + * @brief Secure Real Time Clock (SRTC) interface in Freescale's SNVS module + * + * This file contains Real Time Clock interface for Linux. The Freescale + * SNVS module's Low Power (LP) SRTC functionality is utilized in this driver, + * in non-secure mode. + * + * @ingroup RTC + */ + I feel above several sections of documents can just be in one multiple line comment section. +#include linux/slab.h +#include linux/delay.h +#include linux/rtc.h +#include linux/module.h +#include linux/fs.h +#include linux/init.h +#include linux/interrupt.h +#include linux/platform_device.h +#include linux/uaccess.h +#include linux/io.h +#include linux/sched.h +#include linux/of.h +#include linux/of_device.h + +/* Register definitions */ +#define SNVS_HPSR 0x14/* HP Status Register */ Normally, we have one space rather than tab after #define. +#define SNVS_LPCR 0x38/* LP Control Register */ +#define SNVS_LPSR 0x4C/* LP Status Register */ +#define SNVS_LPSRTCMR 0x50/* LP Secure Real Time Counter MSB Register */ +#define SNVS_LPSRTCLR 0x54/* LP Secure Real Time Counter LSB Register */ +#define SNVS_LPTAR 0x58/* LP Time Alarm Register */ +#define SNVS_LPSMCMR0x5C/* LP Secure Monotonic Counter MSB Register */ +#define SNVS_LPSMCLR0x60/* LP Secure Monotonic Counter LSB
Re: Gmail corrupting spaces in plain-text mail?
I did actually. If anyone has any examples of the plague of question marks that we think are caused by this, let me know and I'll add it to the case. On Thu, Mar 22, 2012 at 3:58 AM, Riku Voipio riku.voi...@linaro.org wrote: On 21 March 2012 18:20, Amber Graner amber.gra...@linaro.org wrote: I spoke to the Google guys about this at Connect, they said they were aware and working on a fix, but that's about all I know at the moment. As paying customers is there a channel we can use to raise the issue? Riku -- Joey STANFORD Engineering Program Manager Office: +1-303-800-6609 http://www.linaro.org/ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Brave 12.03 testers, a call to action
Here are our bold volunteers! Annamalai https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-samsunglt-stable-blob-12.03-release/ Bero https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-freescalelt-stable-open-12.03-release/ https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open-12.03-release/ Mathieu https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob-12.03-release/ Abhishek https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open-12.03-release/ Botao https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open-12.03-release/ Vishal 4460 Chenglie 4430 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-tracking-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-stable-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-master-gcc44-aosp-stable-blob-12.03-release/ (4430 and 4460) Amber 4430, Tony 4460 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc44-kwg-upstream-open-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open-12.03-release/ (4430 and 4460) clap clap clap clap clap clap Here's the process: Abhishek will cut the builds on Monday 3/26, India Morning. He will boottest each tip. Please watch email or IRC in case he needs some help. After the builds are done he will enter the released build to test into the test spreadsheets (build row) listed here. Please test this build exactly. __Test Spreadsheets__ iMX53, iMX6 https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1MlJmY19PQzlJOUY5OXk0SWJYT1E#gid=3 Snowball https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc#gid=3 Origen https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDRDVl9TSHUweUk3eG9ndk9sNGxUVnc#gid=2 Panda https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=5 Vexpress https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=0 __Process__ STarting on Tuesday, please program the builds and boot um up. The tests are documented at the Test Description link on each test sheet. Run through the tests starting with tests that were red in the last release, then tests that were yellow, then the rest and enter in the new results in the spreadsheet in the right column. In this case r12.03. It'll be the column with the build listed in the build row. note which tab you're on. You should see the build name. Also make sure you put the kernel and toolchain that the build is run against. and the build number. Also, and this is new from last time, look at all the bugs in the linaro-android project in launchpad that are marked Fix Committed and if they're fixed, mark them Fix Released with the build you tested. If they're not, please update the bug and set it back to In Progress. When you run into a new issue, please file a bug with the test that was run and the build that it was tested on. For existing issues, please update the bug with the build link that was tested, with a note, still an issue on http://#123,; etc. If you have any questons, call, email or IRC me. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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: Brave 12.03 testers, a call to action
Hi Zach, I think you have missed the vexpress-rtsm builds.There are people who are interested in that build. On 22 March 2012 21:58, Zach Pfeffer zach.pfef...@linaro.org wrote: Here are our bold volunteers! Annamalai https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-samsunglt-stable-blob-12.03-release/ Bero https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-freescalelt-stable-open-12.03-release/ https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open-12.03-release/ Mathieu https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob-12.03-release/ Abhishek https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open-12.03-release/ Botao https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open-12.03-release/ Vishal 4460 Chenglie 4430 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-tracking-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-stable-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-master-gcc44-aosp-stable-blob-12.03-release/ (4430 and 4460) Amber 4430, Tony 4460 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc44-kwg-upstream-open-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open-12.03-release/ (4430 and 4460) clap clap clap clap clap clap Here's the process: Abhishek will cut the builds on Monday 3/26, India Morning. He will boottest each tip. Please watch email or IRC in case he needs some help. After the builds are done he will enter the released build to test into the test spreadsheets (build row) listed here. Please test this build exactly. __Test Spreadsheets__ iMX53, iMX6 https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1MlJmY19PQzlJOUY5OXk0SWJYT1E#gid=3 Snowball https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc#gid=3 Origen https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDRDVl9TSHUweUk3eG9ndk9sNGxUVnc#gid=2 Panda https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=5 Vexpress https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=0 __Process__ STarting on Tuesday, please program the builds and boot um up. The tests are documented at the Test Description link on each test sheet. Run through the tests starting with tests that were red in the last release, then tests that were yellow, then the rest and enter in the new results in the spreadsheet in the right column. In this case r12.03. It'll be the column with the build listed in the build row. note which tab you're on. You should see the build name. Also make sure you put the kernel and toolchain that the build is run against. and the build number. Also, and this is new from last time, look at all the bugs in the linaro-android project in launchpad that are marked Fix Committed and if they're fixed, mark them Fix Released with the build you tested. If they're not, please update the bug and set it back to In Progress. When you run into a new issue, please file a bug with the test that was run and the build that it was tested on. For existing issues, please update the bug with the build link that was tested, with a note, still an issue on http://#123,; etc. If you have any questons, call, email or IRC me. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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: Brave 12.03 testers, a call to action
On 22 March 2012 11:58, Vishal Bhoj vishal.b...@linaro.org wrote: Hi Zach, I think you have missed the vexpress-rtsm builds.There are people who are interested in that build. Okay. Abhishek, would you add this build to the releases and add a tab in the testsheet? On 22 March 2012 21:58, Zach Pfeffer zach.pfef...@linaro.org wrote: Here are our bold volunteers! Annamalai https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-samsunglt-stable-blob-12.03-release/ Bero https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-freescalelt-stable-open-12.03-release/ https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open-12.03-release/ Mathieu https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob-12.03-release/ Abhishek https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open-12.03-release/ Botao https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open-12.03-release/ Vishal 4460 Chenglie 4430 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-tracking-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-stable-blob-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-master-gcc44-aosp-stable-blob-12.03-release/ (4430 and 4460) Amber 4430, Tony 4460 https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc44-kwg-upstream-open-12.03-release/ (4430 and 4460) https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open-12.03-release/ (4430 and 4460) clap clap clap clap clap clap Here's the process: Abhishek will cut the builds on Monday 3/26, India Morning. He will boottest each tip. Please watch email or IRC in case he needs some help. After the builds are done he will enter the released build to test into the test spreadsheets (build row) listed here. Please test this build exactly. __Test Spreadsheets__ iMX53, iMX6 https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDE1MlJmY19PQzlJOUY5OXk0SWJYT1E#gid=3 Snowball https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc#gid=3 Origen https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadDRDVl9TSHUweUk3eG9ndk9sNGxUVnc#gid=2 Panda https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=5 Vexpress https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=0 __Process__ STarting on Tuesday, please program the builds and boot um up. The tests are documented at the Test Description link on each test sheet. Run through the tests starting with tests that were red in the last release, then tests that were yellow, then the rest and enter in the new results in the spreadsheet in the right column. In this case r12.03. It'll be the column with the build listed in the build row. note which tab you're on. You should see the build name. Also make sure you put the kernel and toolchain that the build is run against. and the build number. Also, and this is new from last time, look at all the bugs in the linaro-android project in launchpad that are marked Fix Committed and if they're fixed, mark them Fix Released with the build you tested. If they're not, please update the bug and set it back to In Progress. When you run into a new issue, please file a bug with the test that was run and the build that it was tested on. For existing issues, please update the bug with the build link that was tested, with a note, still an issue on http://#123,; etc. If you have any questons, call, email or IRC me. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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 -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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
Graphics working group components for 2012.03
Hi all, The graphics working group is pleased to announce the 2012.03 release for the following components: - glmark2 * Offscreen rendering support using framebuffer objects. * New command line switch to allow selection of end-of-frame method, - glcompbench * New 'blur' test. * Updated glproxy support. - glproxy * Enhanced selection of EGL vs. GLX based upon new detection API. These are all available for download from their respective project pages, conveniently linked from the project group page at: https://launchpad.net/linaro-graphics-wg The release for the linaro-mm-sig project is being rolled up into the linux-linaro kernel tree (linux-linaro branch of git://git.linaro.org/kernel/linux-linaro-tracking.git) for this cycle, and should see updates between cycles, as well moving forward. Enjoy! cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Graphics working group components for 2012.03 (cont.)
Hi all, Somehow, I completely forgot about the release for the unity-gles project. All OpenGL|ES enablement for the Ubuntu Unity plugin (the Unity3D shell) and the nux library has been merged into the respective trunks on launchpad for those projects (lp:unity, lp:nux), so Linaro will not be releasing those. There are 2012.03 release tarballs for compiz itself (both compiz-core and compiz-plugins-main) at https://launchpad.net/unity-gles. These will support Precise only, due to external library dependencies. cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
Daniel Lezcano daniel.lezc...@linaro.org writes:
On 03/21/2012 10:54 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for
cpu0 only
and why the WFI is not used ?
Daniel Lezcano (7):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
The series looks fine to me in general. This clean-up is applicable
for OMAP3 cpuidle code as well.
Great!
However OMAP3 has a few specific things that cannot be removed as easily:
- the 'valid' flag is used because only certain combinations of power
domains states are possible,
When I look the board-rx51 code I see:
static struct cpuidle_params rx51_cpuidle_params[] = {
/* C1 */
{110 + 162, 5 , 1},
/* C2 */
{106 + 180, 309, 1},
/* C3 */
{107 + 410, 46057, 0},
/* C4 */
{121 + 3374, 46057, 0},
/* C5 */
{855 + 1146, 46057, 1},
/* C6 */
{7580 + 4134, 484329, 0},
/* C7 */
{7505 + 15274, 484329, 1},
};
If C3, C4, C6 are not valid, so AFAICS never used in the cpuidle code
why the values are 'exit_latency' and 'target_residency' specified ? I
mean why don't we have { 0, 0, 0 } ? Is it just for information ?
Yes, because getting those numbers were based on some board-specific
measurements, and we don't want those values to be lost. Also, some
usage patterns might want to (re)enable those states.
When you say re-enable you mean for a custom kernel ?
Yes.
I understand the purpose of this code but it looks a bit tricky and
hard to factor out. Is it acceptable to create a new cpuidle driver
for rx51 then we factor out the code between omap3, omap4 and rx51
when all the code consistent ?
I don't like that idea. All the code is the same, the only thing we
need is the ability to pass in board-specific latency numbers for the
C-states.
Sorry I was not clear, I was not saying duplicating the code. What I
meant is to create a driver:
struct cpuidle_driver rx51_idle_driver = {
.name = rx51_idle,
.owner =THIS_MODULE,
.states = {
{
/* What is in rx51_cpuidle_params */
}
};
We put in there only the valid fields and we keep in a comment the
table with the latency numbers.
Ah, OK. I misunderstood.
Assuming the valid field is for handling the table overwritting, we
can then remove it. By this way, we simplify the next_valid_state
function.
probably we can remove next_valid_state all together after 3.4 since the
new sysfs entry for that feature looks to be queued in linux-next.
Depending if we have rx51 or not, we register the rx51 driver or the
omap3 driver in the init function. That has also the benefit to group
the cpuidle code in the cpuidle34xx file.
yes, but with board-specific data in SoC-specific code, which is not a
clean separation IMO. How would you plan to pass which board it's
running on?
These latency numbers are obviously quite significant when it comes to
the final power consumption, and these values often depend on
board-specific settings. Until there are generic frameworks for
defining all the latencies involved, passing these values in from board
files is absolutly needed.
Yes but before creating the generic framework, we have to do a
transversal cpuidle consolidation across the SoC, factor out the code
when possible, and ensure the consistency between the different
platform and see a common pattern to emerge from this work.
Agreed, but if that means ignoring platform-specific customization, and
not putting in other mechanisms to configure platform specific details,
it is throwing away useful infrastructure.
IMO, any consolidated framework needs some way to customize or pass in
latencies from platform-specific code. Long term, I suppose this needs
to be DT based.
That being said, I do want to see this consolidation happen, so...
In OMAP land, we are in the middle of putting in place a better
framework for defining/tracking the various latencies involved in PM
transitions (using per-device PM Qos.) After that, we will likely be
reworking and revalidating these latency numbers for all
Re: Gmail corrupting spaces in plain-text mail?
On Thu, Mar 22, 2012 at 09:18:36AM -0600, Joey STANFORD wrote: I did actually. If anyone has any examples of the plague of question marks that we think are caused by this, let me know and I'll add it to the case. Now I've had a chance to look into this, it seems that the plague of question marks actually seems to arise out of an interaction between Mutt and my unusual locale settings. Basically if your locale settings don't support the no-breaking space character then Mutt when quoting text for replies will default to a charset which doesn't have it, and will replace all non-representable characters with ? So, it seems that this should only affect people whose mail client settings exclude modern charsets like ISO-8859-n and UTF-8 (in my case, this was an unintentional side-effect). The way Gmail munges the whitespace in replies still feels wrong, but I can avoid the worst of the consequences with a local workaround to my Mutt config. This may affect a few other people out there with unusual settings, but not very many. I think the don't reply to patches via Gmail is still good advice to follow most of the time, but it looks a bit less critical than I initially thought. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Gmail corrupting spaces in plain-text mail?
On 22 March 2012 19:31, Dave Martin dave.mar...@linaro.org wrote: Now I've had a chance to look into this, it seems that the plague of question marks actually seems to arise out of an interaction between Mutt and my unusual locale settings. Basically if your locale settings don't support the no-breaking space character then Mutt when quoting text for replies will default to a charset which doesn't have it, and will replace all non-representable characters with ? So, it seems that this should only affect people whose mail client settings exclude modern charsets like ISO-8859-n and UTF-8 (in my case, this was an unintentional side-effect). Yeah, most people these days don't seem to notice because their clients can cope with the non-breaking-space, but it's still pretty poor on gmail's part to be mangling the text in the first place (not least because it leaves you open to old-school email types who might choose to flame for quoted-printable). On the other hand I have gone at least a year replying to patches on qemu-devel like this without getting any complaints, so maybe all the old-school types have finally got a unicode aware mail client :-) -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/22/2012 07:36 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
On 03/21/2012 10:54 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.comwrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for cpu0 only
and why the WFI is not used ?
Daniel Lezcano (7):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
The series looks fine to me in general. This clean-up is applicable
for OMAP3 cpuidle code as well.
Great!
However OMAP3 has a few specific things that cannot be removed as easily:
- the 'valid' flag is used because only certain combinations of power
domains states are possible,
When I look the board-rx51 code I see:
static struct cpuidle_params rx51_cpuidle_params[] = {
/* C1 */
{110 + 162, 5 , 1},
/* C2 */
{106 + 180, 309, 1},
/* C3 */
{107 + 410, 46057, 0},
/* C4 */
{121 + 3374, 46057, 0},
/* C5 */
{855 + 1146, 46057, 1},
/* C6 */
{7580 + 4134, 484329, 0},
/* C7 */
{7505 + 15274, 484329, 1},
};
If C3, C4, C6 are not valid, so AFAICS never used in the cpuidle code
why the values are 'exit_latency' and 'target_residency' specified ? I
mean why don't we have { 0, 0, 0 } ? Is it just for information ?
Yes, because getting those numbers were based on some board-specific
measurements, and we don't want those values to be lost. Also, some
usage patterns might want to (re)enable those states.
When you say re-enable you mean for a custom kernel ?
Yes.
I understand the purpose of this code but it looks a bit tricky and
hard to factor out. Is it acceptable to create a new cpuidle driver
for rx51 then we factor out the code between omap3, omap4 and rx51
when all the code consistent ?
I don't like that idea. All the code is the same, the only thing we
need is the ability to pass in board-specific latency numbers for the
C-states.
Sorry I was not clear, I was not saying duplicating the code. What I
meant is to create a driver:
struct cpuidle_driver rx51_idle_driver = {
.name = rx51_idle,
.owner =THIS_MODULE,
.states = {
{
/* What is in rx51_cpuidle_params */
}
};
We put in there only the valid fields and we keep in a comment the
table with the latency numbers.
Ah, OK. I misunderstood.
Assuming the valid field is for handling the table overwritting, we
can then remove it. By this way, we simplify the next_valid_state
function.
probably we can remove next_valid_state all together after 3.4 since the
new sysfs entry for that feature looks to be queued in linux-next.
Oh, that could be very cool. That will remove a reasonable chunk of code.
Depending if we have rx51 or not, we register the rx51 driver or the
omap3 driver in the init function. That has also the benefit to group
the cpuidle code in the cpuidle34xx file.
yes, but with board-specific data in SoC-specific code, which is not a
clean separation IMO. How would you plan to pass which board it's
running on?
I was thinking using the same code path than the array overriding for
cpuidle_data initialization. I did not looked at this initialization
part in details neither the order.
These latency numbers are obviously quite significant when it comes to
the final power consumption, and these values often depend on
board-specific settings. Until there are generic frameworks for
defining all the latencies involved, passing these values in from board
files is absolutly needed.
Yes but before creating the generic framework, we have to do a
transversal cpuidle consolidation across the SoC, factor out the code
when possible, and ensure the consistency between the different
platform and see a common pattern to emerge from this work.
Agreed, but if that means ignoring platform-specific customization, and
not putting in other mechanisms to configure platform specific details,
it is throwing away useful infrastructure.
Yes, I agree.
IMO, any consolidated framework needs some way to customize or pass in
latencies from platform-specific code. Long term, I suppose this needs
to be DT
ARM porting jam on Friday
Still plenty of things to fix, and not long till release-time. Friday is the day to come fix some ARM bugs. You know you want to. You have a choice between the usual FTBFS issues listed here: http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-report.html and multiarch cross-dependency/cross-building issues summarised here: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuildStatus with logfiles here http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html There is a pile of stuff, much of which is _really easy_. This page tells you all you need to know for filing simple multiarch metadata bugreports: http://wiki.debian.org/Multiarch/CrossDependencies Please come along to #linaro @ freenode and get stuck in with a few bugs. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
