What kernel version will be in this months release?
3.1 or 3.2? Android seems to be going with 3.2 judging by a pre-release version, what about the kernel working group and Ubuntu? And where do we find out about these things? Because I find it a bit too late to not find out until the releases is done. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro powertop doesn't work well on a single core ARM SoC
Hi Tony/Amit,
anybody has tried to use powertop from linaro on a single core ARM
SoC? What i am using is
git://android.git.linaro.org/platform/external/powertop.git.
I got two questions:
1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
number(-1), then i made the following change to make it work:
powertop: fix segment fault for single cpu env
Signed-off-by: Barry Song
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 29fc72c..c56c746 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -302,6 +302,9 @@ void enumerate_cpus(void)
model = strtoull(c, NULL, 10);
}
}
+
+ if (number == -1)
+ number = 0;
if (strncasecmp(line, "bogomips\t", 9) == 0) {
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);
2. after fixing problem1, powertop can run on PrimaII, but i always
get 0.0% for every p states as you can see from attached pic.
but if we check cpufreq stats in
/sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
based on ondemand.
# cat time_in_state
80 2064
60 181
40 341
20 60381
# cat trans_table
From :To
:80604020
80: 0131314
60: 5 0 3 5
40: 5 0 011
20:29 0 0 0
# cat total_trans
98
does anyone have experiences about it?
Thanks
barry
<>___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro powertop doesn't work well on a single core ARM SoC
Hi Barry,
You fix for invalid cpu id looks fine. As for the P states this new
powertop combines with the cpuidle numbers. so if the system is highly
idle it means processor is idle and hence P states is shown as 0.
Thanks,
Amit Daniel
On 12 December 2011 15:55, Barry Song <21cn...@gmail.com> wrote:
> Hi Tony/Amit,
> anybody has tried to use powertop from linaro on a single core ARM
> SoC? What i am using is
> git://android.git.linaro.org/platform/external/powertop.git.
> I got two questions:
> 1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
> number(-1), then i made the following change to make it work:
>
> powertop: fix segment fault for single cpu env
>
> Signed-off-by: Barry Song
>
> diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
> index 29fc72c..c56c746 100644
> --- a/cpu/cpu.cpp
> +++ b/cpu/cpu.cpp
> @@ -302,6 +302,9 @@ void enumerate_cpus(void)
> model = strtoull(c, NULL, 10);
> }
> }
> +
> + if (number == -1)
> + number = 0;
> if (strncasecmp(line, "bogomips\t", 9) == 0) {
> handle_one_cpu(number, vendor, family, model);
> set_max_cpu(number);
>
> 2. after fixing problem1, powertop can run on PrimaII, but i always
> get 0.0% for every p states as you can see from attached pic.
> but if we check cpufreq stats in
> /sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
> based on ondemand.
>
> # cat time_in_state
> 80 2064
> 60 181
> 40 341
> 20 60381
>
> # cat trans_table
> From : To
> : 80 60 40 20
> 80: 0 13 13 14
> 60: 5 0 3 5
> 40: 5 0 0 11
> 20: 29 0 0 0
>
> # cat total_trans
> 98
>
> does anyone have experiences about it?
>
> Thanks
> barry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Upstreaming patches for u-boot?
On Fri, 2011-12-09 at 17:17 -0700, John Rigby wrote: > On Fri, Dec 9, 2011 at 1:15 PM, Lalancette, Christopher > wrote: > > Hello John, > > I'm currently working on bringing up a new OMAP4 board that is > > similar in many respects to the pandaboard. While playing around with > > the panda, I've noticed that upstream u-boot (from denx.de) has several > > problems, starting with getting the USB/Ethernet hub up and running. > > Additionally, I've noticed that the u-boot-linaro-stable tree seems to > > work well on the same hardware. > > > > Is there currently a plan for upstreaming some of the patches that > > are currently being carried in u-boot-linaro-stable? If you needed some > > help with this, I think I could find a bit of time to help out, though I > > would only be able to personally test OMAP4 patches. Before starting > > anything, though, I wanted to check in to see if there was a plan or if > > this work was ongoing. > > > Hi Chris, > > Yes help would be wonderful. The patches that make usb work were > "orphaned" by the original contributer and I grabbed them and made > them work for me. They need extra clean up to go upstream which I > have not had time todo. I will be doing a new u-boot-linaro-stable > once upstream v2011.12 comes out. At that time it would be great if > you could grab the relevant patches, clean them up and send upstream. > I have no plans to do this right now so if you want to do it that > would be fantastic. > OK, great. I'll take a closer look at those patches and see what I can do to make it more palatable to upstream. I'll also want to get the patches for OMAP4460 upstream, as our board is based on that and SPL doesn't even start with current u-boot upstream. > I'll ping you when I have a new -stable tree working. If you don't > notice on your own. Yeah, a direct ping would be appreciated. I try to keep up, but there is just too much mail sometimes :). Thanks, -- Chris Lalancette ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 01/06] MFD: DA9052/53 MFD core module v10
The DA9052/53 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. This patch is functionally tested on Samsung SMDKV6410. Signed-off-by: David Dajun Chen Signed-off-by: Ashish Jangam --- Changes since v10: - Add regmap-cache support - Add regulator devices as MFD children - Replace && operator with || operator - Fix a memory leak in i2c_probe - Remove i2c_client from struct da9052 Changes since v9: - Add support for regmap_irq - Patch split into I2C, ADC and SPI - Support unconditional registration of all the regulators - Replace magic number with define - Remove user define bus_type from struct da9052 - Use spi_device_id - implemented in spi incremental patch - Remove ADC deadlock issue - implemented in ADC incremental patch Changes since v8: - Add read/write mask flag for SPI Changes since v7: - Replace ADC polling with interrupt mechanism - Move macros related to battery module IRQs to header file Changes since v6: - Move inlined device I/O functions to header file Changes since v5: - Inline device I/O - Unhandle IRQ return IRQ_NONE - Remove register address conversion Changes since v4: - Modify KConfig - Use device registration for detemining chip id - Remove preprocessor directive with runtime bustype variable - Replace module_init() for spi with subsys_initcall() - Remove platform string from MODULE_ALIAS of spi module. 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 | 16 + drivers/mfd/Makefile |4 + drivers/mfd/da9052-core.c | 690 ++ drivers/mfd/da9052-i2c.c | 140 +++ include/linux/mfd/da9052/da9052.h | 129 +++ include/linux/mfd/da9052/pdata.h | 40 ++ include/linux/mfd/da9052/reg.h| 749 + 7 files changed, 1768 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/da9052-core.c create mode 100644 drivers/mfd/da9052-i2c.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 f1391c2..baced42 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -328,6 +328,22 @@ 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_I2C + bool "Support Dialog Semiconductor DA9052/53 PMIC variants with I2C" + select REGMAP_I2C + select REGMAP_IRQ + 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 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 b2292eb..484f209 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -67,6 +67,10 @@ endif obj-$(CONFIG_UCB1400_CORE) += ucb1400_core.o obj-$(CONFIG_PMIC_DA903X) += da903x.o + +obj-$(CONFIG_PMIC_DA9052) += da9052-core.o +obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o + max8925-objs := max8925-core.o max8925-i2c.o obj-$(CONFIG_MFD_MAX8925) += max8925.o obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c new file mode 100644 index 000..a7c115c --- /dev/null +++ b/drivers/mfd/da9052-core.c @@ -0,0 +1,690 @@ +/* + * Device access for Dialog DA9052 PMICs. + * + * Copyright(c) 2011 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +
[PATCH 02/06] MFD: DA9052/53 MFD core module add ADC support v2
This patch adds ADC support to the DA9052/53 MFD core module.
This patch is functionally tested on Samsung SMDKV6410.
Signed-off-by: David Dajun Chen
Signed-off-by: Ashish Jangam
---
Changes since v1:
- Fix a memory leak in function da9052_adc_manual_read
---
drivers/mfd/da9052-core.c | 188 +
include/linux/mfd/da9052/da9052.h | 22 +
2 files changed, 210 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index a7c115c..5fa7bb9 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -315,6 +315,162 @@ static bool da9052_reg_volatile(struct device *dev,
unsigned int reg)
}
}
+/*
+ * TBAT look-up table is computed from the R90 reg (8 bit register)
+ * reading as below. The battery temperature is in milliCentigrade
+ * TBAT = (1/(t1+1/298) - 273) * 1000 mC
+ * where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255))
+ * Default values are R25 = 10e3, B = 3380, ITBAT = 50e-6
+ * Example:
+ * R25=10E3, B=3380, ITBAT=50e-6, ADCVAL=62d calculates
+ * TBAT = 20015 mili degrees Centrigrade
+ *
+*/
+static const int32_t tbat_lookup[255] = {
+ 183258, 144221, 124334, 111336, 101826, 94397, 88343, 83257,
+ 78889, 75071, 71688, 68656, 65914, 63414, 61120, 59001,
+ 570366, 55204, 53490, 51881, 50364, 48931, 47574, 46285,
+ 45059, 43889, 42772, 41703, 40678, 39694, 38748, 37838,
+ 36961, 36115, 35297, 34507, 33743, 33002, 32284, 31588,
+ 30911, 30254, 29615, 28994, 28389, 27799, 27225, 26664,
+ 26117, 25584, 25062, 24553, 24054, 23567, 23091, 22624,
+ 22167, 21719, 21281, 20851, 20429, 20015, 19610, 19211,
+ 18820, 18436, 18058, 17688, 17323, 16965, 16612, 16266,
+ 15925, 15589, 15259, 14933, 14613, 14298, 13987, 13681,
+ 13379, 13082, 12788, 12499, 12214, 11933, 11655, 11382,
+ 2, 10845, 10582, 10322, 10066, 9812, 9562, 9315,
+ 9071, 8830, 8591, 8356, 8123, 7893, 7665, 7440,
+ 7218, 6998, 6780, 6565, 6352, 6141, 5933, 5726,
+ 5522, 5320, 5120, 4922, 4726, 4532, 4340, 4149,
+ 3961, 3774, 3589, 3406, 3225, 3045, 2867, 2690,
+ 2516, 2342, 2170, 2000, 1831, 1664, 1498, 1334,
+ 1171, 1009, 849, 690, 532, 376, 221, 67,
+ -84, -236, -386, -535, -683, -830, -975, -1119,
+ -1263, -1405, -1546, -1686, -1825, -1964, -2101, -2237,
+ -2372, -2506, -2639, -2771, -2902, -3033, -3162, -3291,
+ -3418, -3545, -3671, -3796, -3920, -4044, -4166, -4288,
+ -4409, -4529, -4649, -4767, -4885, -5002, -5119, -5235,
+ -5349, -5464, -5577, -5690, -5802, -5913, -6024, -6134,
+ -6244, -6352, -6461, -6568, -6675, -6781, -6887, -6992,
+ -7096, -7200, -7303, -7406, -7508, -7609, -7710, -7810,
+ -7910, -8009, -8108, -8206, -8304, -8401, -8497, -8593,
+ -8689, -8784, -8878, -8972, -9066, -9159, -9251, -9343,
+ -9435, -9526, -9617, -9707, -9796, -9886, -9975, -10063,
+ -10151, -10238, -10325, -10412, -10839, -10923, -11007, -11090,
+ -11173, -11256, -11338, -11420, -11501, -11583, -11663, -11744,
+ -11823, -11903, -11982
+};
+
+static const u8 chan_mux[DA9052_ADC_VBBAT + 1] = {
+ [DA9052_ADC_VDDOUT] = DA9052_ADC_MAN_MUXSEL_VDDOUT,
+ [DA9052_ADC_ICH]= DA9052_ADC_MAN_MUXSEL_ICH,
+ [DA9052_ADC_TBAT] = DA9052_ADC_MAN_MUXSEL_TBAT,
+ [DA9052_ADC_VBAT] = DA9052_ADC_MAN_MUXSEL_VBAT,
+ [DA9052_ADC_IN4]= DA9052_ADC_MAN_MUXSEL_AD4,
+ [DA9052_ADC_IN5]= DA9052_ADC_MAN_MUXSEL_AD5,
+ [DA9052_ADC_IN6]= DA9052_ADC_MAN_MUXSEL_AD6,
+ [DA9052_ADC_VBBAT] = DA9052_ADC_MAN_MUXSEL_VBBAT
+};
+
+enum da9052_auxadc {
+ VDDOUT = DA9052_ADC_VDDOUT,
+ ICH = DA9052_ADC_ICH,
+ TBAT = DA9052_ADC_TBAT,
+ VBAT = DA9052_ADC_VBAT,
+ IN4 = DA9052_ADC_IN4,
+ IN5 = DA9052_ADC_IN5,
+ IN6 = DA9052_ADC_IN6,
+ VBBAT = DA9052_ADC_VBBAT,
+};
+
+struct da9052_auxadc_req {
+ struct list_head list;
+ enum da9052_auxadc input;
+ struct completion done;
+};
+
+int da9052_adc_manual_read(struct da9052 *da9052, unsigned char channel)
+{
+ struct da9052_auxadc_req *req;
+ int ret;
+ unsigned short calc_data;
+ unsigned short data;
+ unsigned char mux_sel;
+
+ if (channel > DA9052_ADC_VBBAT)
+ return -EINVAL;
+
+ req = kzalloc(sizeof(*req), GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+
+ init_completion(&req->done);
+ req->input = channel;
+
+ mutex_lock(&da9052->auxadc_lock);
+
+ /* Channel gets activated on enabling the Conversion bit */
+ mux_sel = chan_mux[channel] | DA9052_ADC_MAN_MAN_CONV;
+
+ if (da9052->auxadc_active) {
+ ret = -EBUSY;
+ goto err;
+ }
+
+ /* Enqueue the request */
+ list_add(&req->list, &da9052->auxadc_pending);
+
+ ret = da9052_reg_write(da9
[PATCH 03/06] MFD: DA9052/53 MFD core module add SPI support v2
This patch add SPI support for DA9052/53 MFD core module.
This patch is functionally tested on Samsung SMDKV6410.
Signed-off-by: David Dajun Chen
Signed-off-by: Ashish Jangam
---
Changes since v1:
- Remove spi_dev from struct da9052
- Move regmap_config due to added support of regmap cache
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile |1 +
drivers/mfd/da9052-spi.c | 115 ++
3 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/da9052-spi.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index baced42..c8322ee 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -332,6 +332,18 @@ config PMIC_DA9052
bool
select MFD_CORE
+config MFD_DA9052_SPI
+ bool "Support Dialog Semiconductor DA9052/53 PMIC variants with SPI"
+ select REGMAP_SPI
+ select REGMAP_IRQ
+ 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/53 PMIC variants with I2C"
select REGMAP_I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 484f209..d5f5743 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_UCB1400_CORE)+= ucb1400_core.o
obj-$(CONFIG_PMIC_DA903X) += da903x.o
obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
+obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
max8925-objs := max8925-core.o max8925-i2c.o
diff --git a/drivers/mfd/da9052-spi.c b/drivers/mfd/da9052-spi.c
new file mode 100644
index 000..cdbc7ca
--- /dev/null
+++ b/drivers/mfd/da9052-spi.c
@@ -0,0 +1,115 @@
+/*
+ * SPI access for Dialog DA9052 PMICs.
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+ *
+ * Author: David Dajun Chen
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static int da9052_spi_probe(struct spi_device *spi)
+{
+ int ret;
+ const struct spi_device_id *id = spi_get_device_id(spi);
+ struct da9052 *da9052 = kzalloc(sizeof(struct da9052), GFP_KERNEL);
+
+ if (!da9052)
+ return -ENOMEM;
+
+ spi->mode = SPI_MODE_0 | SPI_CPOL;
+ spi->bits_per_word = 8;
+ spi_setup(spi);
+
+ da9052->dev = &spi->dev;
+ da9052->chip_irq = spi->irq;
+
+ dev_set_drvdata(&spi->dev, da9052);
+
+ da9052_regmap_config.read_flag_mask = 1;
+ da9052_regmap_config.write_flag_mask = 0;
+
+ da9052->regmap = regmap_init_spi(spi, &da9052_regmap_config);
+ if (IS_ERR(da9052->regmap)) {
+ ret = PTR_ERR(da9052->regmap);
+ dev_err(&spi->dev, "Failed to allocate register map: %d\n",
+ ret);
+ goto err;
+ }
+
+ ret = da9052_device_init(da9052, id->driver_data);
+ if (ret != 0)
+ goto err;
+
+ return 0;
+
+err:
+ kfree(da9052);
+ return ret;
+}
+
+static int da9052_spi_remove(struct spi_device *spi)
+{
+ struct da9052 *da9052 = dev_get_drvdata(&spi->dev);
+
+ da9052_device_exit(da9052);
+ kfree(da9052);
+
+ return 0;
+}
+
+static struct spi_device_id da9052_spi_id[] = {
+ {"da9052", DA9052},
+ {"da9053-aa", DA9053_AA},
+ {"da9053-ba", DA9053_BA},
+ {"da9053-bb", DA9053_BB},
+ {}
+};
+
+static struct spi_driver da9052_spi_driver = {
+ .probe = da9052_spi_probe,
+ .remove = __devexit_p(da9052_spi_remove),
+ .id_table = da9052_spi_id,
+ .driver = {
+ .name = "da9052",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init da9052_spi_init(void)
+{
+ int ret;
+
+ ret = spi_register_driver(&da9052_spi_driver);
+ if (ret != 0) {
+ pr_err("Failed to register DA9052 SPI driver, %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+subsys_initcall(da9052_spi_init);
+
+static void __exit da9052_spi_exit(void)
+{
+ spi_unregister_driver(&da9052_spi_driver);
+}
+module_exit(da9052_spi_exit);
+
+MODULE_AUTHOR("David Dajun Chen ");
+MODULE_DESCRIPTION("SPI driver for Dialog DA9052 PMIC");
+MODULE_LICENSE("GPL");
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lina
Re: What kernel version will be in this months release?
Generally the landing teams can dictate what version is going into the release On Mon, Dec 12, 2011 at 2:06 AM, Jon Medhurst (Tixy) wrote: > 3.1 or 3.2? > For 11.12, Ubuntu we're targeting 3.2 , and for Android it will be 3.0. If there's enough time to get the mali graphics going in 3.2 then Android will get 3.2 as well. > Android seems to be going with 3.2 judging by a pre-release version, > what about the kernel working group and Ubuntu? > > And where do we find out about these things? Because I find it a bit too > late to not find out until the releases is done. > There was supposed to be a planning meeting so that the LTs would find out from platform what the plans are. Ryan should be able to get you that info. > -- > Tixy > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Angus Ainslie Team Lead, Samsung Landing Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-next not booting on snowball
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2011 06:31 PM, Daniel Lezcano wrote:
> On 12/02/2011 01:11 AM, Nicolas Pitre wrote:
>> On Fri, 2 Dec 2011, Daniel Lezcano wrote:
>
>>> On 12/01/2011 08:03 PM, Nicolas Pitre wrote:
Please have a look at this email:
http://article.gmane.org/gmane.linux.ports.arm.kernel/141386
There are two patches in there which should help you get
some
> debugging
info out.
>>>
>>>
>>> Thanks Nicolas,
>>>
>>> I have applied the patches and I get:
>>>
>>> -
>>>
>>> <6>Booting Linux on physical CPU 0 <6>Initializing cgroup
>>> subsys cpuset <6>Initializing cgroup subsys cpu <5>Linux
>>> version 3.2.0-rc2+ (dlezcano@monster) (gcc version 4.3.2
>>> (Debian 4.3.2-1.1) ) #7 SMP PREEMPT Thu Dec 1 2 3:58:34 CET
>>> 2011 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7),
>>> cr=10c5387f CPU: PIPT / VIPT nonaliasing data cache, VIPT
>>> aliasing
> instruction cache
>>> Machine: Calao Systems Snowball platform <4>Ignoring
>>> unrecognised tag 0x41000403 Memory policy: ECC disabled, Data
>>> cache writealloc
>>>
>>> -
>>>
>>> I am not able to understand these informations, I hope they
>>> can
> help to
>>> understand the problem.
>>>
>>> Is there something else I can do to help ?
>
>> Yes. Either you have access to a fancy debugger and then you
>> could trace what happens from the moment devicemaps_init() is
>> entered.
>
>> Or, using the good old way, just insert a couple of
>
>> printk("%s:%s line %d\n", __FILE__, __func__, __LINE__);
>
>> in a couple places (still with the 2 earlier patches applied).
>> Good locations for those traces would be:
>
>> - Upon entering devicemaps_init() to confirm it makes that far.
>
>> - Just before and right after the call to mdesc->map_io(), still
>> in devicemaps_init().
>
>> - If you don't see the trace after mdesc->map_io(), then the
> problem is
>> most likely in u8500_map_io(), in which case you should add more
>> traces in there to narrow the problem area down to the
>> problematic call.
>
> The kernel hangs at:
>
> u8500_map_io -> ux500_map_io -> ux500_read_asicid(addr=9001dbf4),
> base=9001d000 -> readl(__io_address(9001dbf4)=f901dbf4);
>
> But when I try with the next patch in the git where it supposed to
> boot, the hang appears at the same place :/
>
> Any ideas ?
Does anyone have some clues or ideas I can investigate ?
I am really not familiar with this part.
- --
Facebook |
Twitter |
Re: linux-next not booting on snowball
On Mon, 12 Dec 2011, Daniel Lezcano wrote: > Does anyone have some clues or ideas I can investigate ? > I am really not familiar with this part. See the next suggestion I gave you in my previous email. You could also work with Linus Walleij who maintains this architecture, and who has access to the hardware while I don't. I already summarized the problem to him privately. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What kernel version will be in this months release?
On 12 December 2011 15:40, Angus Ainslie wrote: > Generally the landing teams can dictate what version is going into the release That's my understanding too. But is life always that simple? ;-) > On Mon, Dec 12, 2011 at 2:06 AM, Jon Medhurst (Tixy) wrote: >> 3.1 or 3.2? >> > > For 11.12, Ubuntu we're targeting 3.2 , and for Android it will be > 3.0. If there's enough time to get the mali graphics going in 3.2 then > Android will get 3.2 as well. > >> Android seems to be going with 3.2 judging by a pre-release version, >> what about the kernel working group and Ubuntu? >> >> And where do we find out about these things? Because I find it a bit too >> late to not find out until the releases is done. >> > > There was supposed to be a planning meeting so that the LTs would find > out from platform what the plans are. Ryan should be able to get you > that info. I wasn't on the call on Thurs as I was visiting ARM in Cambridge, so I'm out of the loop at the moment. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH]: Initialize the USB phy during panda misc_init_r
Hi John,
Attached is a somewhat cleaned up version of the USB patch that seems
to work on my pandaboard. I figured you could include it in your new
u-boot-linaro-stable repository in lieu of the other one.
I'm not quite sure how you want patches to work; do you want me to
submit patches to you, or should I just try to send them to upstream
u-boot as I have them?
Thanks,
--
Chris Lalancette
From a93c7563e440f952211b0e2c09e63cf0e4395315 Mon Sep 17 00:00:00 2001
From: Chris Lalancette
Date: Mon, 12 Dec 2011 10:16:19 -0500
Subject: [PATCH] Initialize the USB phy during panda misc_init_r.
This allows the USB hub (along with ethernet) to work
within Linux.
Signed-off-by: Chris Lalancette
---
arch/arm/include/asm/arch-omap4/omap.h | 42
board/ti/panda/panda.c | 16
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap4/omap.h b/arch/arm/include/asm/arch-omap4/omap.h
index 4d8c89f..bdda199 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -165,6 +165,48 @@ struct control_lpddr2io_regs {
unsigned int control_lpddr2io2_2;
unsigned int control_lpddr2io2_3;
};
+
+struct omap4_scrm_regs {
+ u32 revision; /* 0x */
+ u32 pad00[63];
+ u32 clksetuptime; /* 0x0100 */
+ u32 pmicsetuptime; /* 0x0104 */
+ u32 pad01[2];
+ u32 altclksrc; /* 0x0110 */
+ u32 pad02[2];
+ u32 c2cclkm; /* 0x011c */
+ u32 pad03[56];
+ u32 extclkreq; /* 0x0200 */
+ u32 accclkreq; /* 0x0204 */
+ u32 pwrreq; /* 0x0208 */
+ u32 pad04[1];
+ u32 auxclkreq0; /* 0x0210 */
+ u32 auxclkreq1; /* 0x0214 */
+ u32 auxclkreq2; /* 0x0218 */
+ u32 auxclkreq3; /* 0x021c */
+ u32 auxclkreq4; /* 0x0220 */
+ u32 auxclkreq5; /* 0x0224 */
+ u32 pad05[3];
+ u32 c2cclkreq; /* 0x0234 */
+ u32 pad06[54];
+ u32 auxclk0; /* 0x0310 */
+ u32 auxclk1; /* 0x0314 */
+ u32 auxclk2; /* 0x0318 */
+ u32 auxclk3; /* 0x031c */
+ u32 auxclk4; /* 0x0320 */
+ u32 auxclk5; /* 0x0324 */
+ u32 pad07[54];
+ u32 rsttime_reg; /* 0x0400 */
+ u32 pad08[6];
+ u32 c2crstctrl; /* 0x041c */
+ u32 extpwronrstctrl; /* 0x0420 */
+ u32 pad09[59];
+ u32 extwarmrstst_reg; /* 0x0510 */
+ u32 apewarmrstst_reg; /* 0x0514 */
+ u32 pad10[1];
+ u32 c2cwarmrstst_reg; /* 0x051C */
+};
+
#endif /* __ASSEMBLY__ */
/*
diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index b4271fb..6f847c4 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -33,6 +33,8 @@ const struct omap_sysinfo sysinfo = {
"Board: OMAP4 Panda\n"
};
+struct omap4_scrm_regs *const scrm = (struct omap4_scrm_regs *)0x4a30a000;
+
/**
* @brief board_init
*
@@ -62,6 +64,20 @@ int board_eth_init(bd_t *bis)
*/
int misc_init_r(void)
{
+ if (omap_revision() != OMAP4430_ES1_0) {
+ /* Enable the USB phy */
+ /* enable software ioreq */
+ sr32(&scrm->auxclk3, 8, 1, 0x1);
+ /* set for sys_clk (38.4MHz) */
+ sr32(&scrm->auxclk3, 1, 2, 0x0);
+ /* set divisor to 2 */
+ sr32(&scrm->auxclk3, 16, 4, 0x1);
+ /* set the clock source to active */
+ sr32(&scrm->altclksrc, 0, 1, 0x1);
+ /* enable clocks */
+ sr32(&scrm->altclksrc, 2, 2, 0x3);
+ }
+
return 0;
}
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
11.12 Android toolchain
Hi, The next RC of the Android toolchain 11.12 (this is more than likely identical to the final) is ready. https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.12/#build=5 It updates to the 11.12 release from the toolchain WG and makes sure gold is built with gcc 4.5 so we don't get dependencies on a current libstdc++. I'm updating all official builds. ttyl bero ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC] sched: Ensure cpu_power periodic update
With a lot of small tasks, the softirq sched is nearly never called
when no_hz is enable. In this case the load_balance is mainly called with
the newly_idle mode which doesn't update the cpu_power.
Add a next_update field which ensure a maximum update period when
there is short activity
Signed-off-by: Vincent Guittot
---
include/linux/sched.h |1 +
kernel/sched/fair.c | 24
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 64527c4..7178446 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -903,6 +903,7 @@ struct sched_group_power {
* single CPU.
*/
unsigned int power, power_orig;
+ unsigned long next_update;
/*
* Number of busy cpus in this group.
*/
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a4d2b7a..809f484 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -215,6 +215,8 @@ calc_delta_mine(unsigned long delta_exec, unsigned long
weight,
const struct sched_class fair_sched_class;
+static unsigned long __read_mostly max_load_balance_interval = HZ/10;
+
/**
* CFS operations on generic schedulable entities:
*/
@@ -3786,6 +3788,11 @@ void update_group_power(struct sched_domain *sd, int cpu)
struct sched_domain *child = sd->child;
struct sched_group *group, *sdg = sd->groups;
unsigned long power;
+ unsigned long interval;
+
+ interval = msecs_to_jiffies(sd->balance_interval);
+ interval = clamp(interval, 1UL, max_load_balance_interval);
+ sdg->sgp->next_update = jiffies + interval;
if (!child) {
update_cpu_power(sd, cpu);
@@ -3893,12 +3900,15 @@ static inline void update_sg_lb_stats(struct
sched_domain *sd,
* domains. In the newly idle case, we will allow all the cpu's
* to do the newly idle load balance.
*/
- if (idle != CPU_NEWLY_IDLE && local_group) {
- if (balance_cpu != this_cpu) {
- *balance = 0;
- return;
- }
- update_group_power(sd, this_cpu);
+ if (local_group) {
+ if (idle != CPU_NEWLY_IDLE) {
+ if (balance_cpu != this_cpu) {
+ *balance = 0;
+ return;
+ }
+ update_group_power(sd, this_cpu);
+ } else if (time_after_eq(jiffies, group->sgp->next_update))
+ update_group_power(sd, this_cpu);
}
/* Adjust by relative CPU power of the group */
@@ -4917,8 +4927,6 @@ void select_nohz_load_balancer(int stop_tick)
static DEFINE_SPINLOCK(balancing);
-static unsigned long __read_mostly max_load_balance_interval = HZ/10;
-
/*
* Scale the max load_balance interval with the number of CPUs in the system.
* This trades load-balance latency on larger machines for less cross talk.
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
On Mon, Dec 12, 2011 at 11:47 AM, Andrew Lunn wrote: > Hi Mike > > +int clk_register_gate(struct device *dev, const char *name, unsigned long > flags, > + struct clk *fixed_parent, void __iomem *reg, u8 > bit_idx, > + int set_to_enable) > + > > How do you suggest handling gated clocks which are already running > when calling the register function? > > On my kirkwood bases system, the bootloader has already turned on a > number of clocks. It does not seem right to start messing with > clk->enable_count and clk->prepare_count. Could clk_register_gate() > have one more parameter, a bool indicating running? I don't like this approach. If the bool for a particular clk is statically defined then it could be wrong (bootloader/kernel mismatch). I've been thinking of adding a clk->ops->init callback in clk_init, which is defined for a platform to use however the author sees fit. There have been a few cases where it would be nice to "init" a clk only once, when it is registered. That code could also handle detecting if a clk is enabled or not. On the other hand we already have a .get_parent callback which is only good for figuring out which parent a mux clk is using... maybe a .is_enabled or .get_enabled would be a good idea which also served the purpose of dynamically determining whether a clk is disabled or running. In general though I think we should try to keep the solution in the core code, not by having platform code pass in a bool. > The kirkwood mach code keeps a bitmap of which platform_data init > functions are called from the board file. In a late_initcall function > it then enables and disables clocks as needed. What i was thinking is > i can ask the hardware what clocks are already running before i > register them and register them as running/not running. Then let the > driver probe functions use the API to enable clocks which are really > needed. In a late_initcall function, i would then call clk_disable(), > clk_unprepare() on clocks which the boot loader started, thus turning > them off if no driver has claimed them. The problem here is that you're solving the "disabled unused clks" issue in platform code. I've started to lay out a little groundwork for that with a flag in struct clk: http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=include/linux/clk.h;h=3b0eb3f1caf1d6346b62c785b74a648587bfcc7f;hb=586c6e8922a889a2893ba4467bb3d13b471656a9#l35 The idea behind CLK_IGNORE_UNUSED flag on line 35 is that the common clk framework can walk the tree (probably as part of a late_initcall, as you suggested) and disable any clks that aren't already enabled and don't have this flag set. This involves zero platform-specific code, but I haven't gotten around to introducing the feature yet as I'm really trying to minimize footprint for the core code (and I'm not doing a good job of that since it keeps growing). Regards, Mike > Is this how you envisage it working? > > Thanks > Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
Hi Mike +int clk_register_gate(struct device *dev, const char *name, unsigned long flags, + struct clk *fixed_parent, void __iomem *reg, u8 bit_idx, +int set_to_enable) + How do you suggest handling gated clocks which are already running when calling the register function? On my kirkwood bases system, the bootloader has already turned on a number of clocks. It does not seem right to start messing with clk->enable_count and clk->prepare_count. Could clk_register_gate() have one more parameter, a bool indicating running? The kirkwood mach code keeps a bitmap of which platform_data init functions are called from the board file. In a late_initcall function it then enables and disables clocks as needed. What i was thinking is i can ask the hardware what clocks are already running before i register them and register them as running/not running. Then let the driver probe functions use the API to enable clocks which are really needed. In a late_initcall function, i would then call clk_disable(), clk_unprepare() on clocks which the boot loader started, thus turning them off if no driver has claimed them. Is this how you envisage it working? Thanks Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
> I don't like this approach. If the bool for a particular clk is > statically defined then it could be wrong (bootloader/kernel > mismatch). > > I've been thinking of adding a clk->ops->init callback in clk_init, > which is defined for a platform to use however the author sees fit. > There have been a few cases where it would be nice to "init" a clk > only once, when it is registered. That code could also handle > detecting if a clk is enabled or not. > > On the other hand we already have a .get_parent callback which is only > good for figuring out which parent a mux clk is using... maybe a > .is_enabled or .get_enabled would be a good idea which also served the > purpose of dynamically determining whether a clk is disabled or > running. > > In general though I think we should try to keep the solution in the > core code, not by having platform code pass in a bool. Hi Mike How about simply reading the bit in the control register? You are already doing a read/modify/write when enabling/disabling the clock, so it seems reasonably safe to assume the read gives you the current state. For those platforms which this does not work, you could add another flag disabling this read to get the initial state. Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Presentation on benchmarking techniques
Hi there. I did a presentation on benchmarking techniques recently that covered our method, measuring, the statistics, and some future directions like STM. A copy is available at: http://people.linaro.org/~michaelh/presentations/Benchmarking%20Techniques%20r6.pdf The notes version is a bit more readable: http://people.linaro.org/~michaelh/presentations/Benchmarking%20Techniques%20Notes%20r6.pdf You can also get the original from Launchpad: bzr branch lp:~michaelh1/+junk/benchmarking-techniques -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 01/06] MFD: DA9052/53 MFD core module v10
On Mon, Dec 12, 2011 at 08:06:56PM +0530, Ashish Jangam wrote: > The DA9052/53 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. > This patch is functionally tested on Samsung SMDKV6410. Reviewed-by: Mark Brown Looking good now! Samuel, this uses regmap-irq so either I can carry this or you can merge: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git topic/irq into your tree to get the changes that the driver depends on. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
