linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Vincent Guittot

Hi, I'd like to do some tests with cpuidle on my panda board but i'm facing some issues: Originally, i'd like to use the Linaro developer image which uses the landing team branch tilt-linux-linaro-3.1 but the omap4 cpuidle driver only works when cpu1 is off whereas i'd like to do some test with both cpus. The android kernel has got a cpuidle driver which can enter C-states when both cpus are running and I was wondering if there is a plan to merge this driver into the tilt-linux-linaro-x.x branch ? maybe in 3.2 ? Then, when I'm testing the landing-panda-11.12-release android image on my panda board revA1, the cpuidle is using only C0 state (WFI) according to cpuidle stats. My test sequence: prevent suspend with: echo qwerty > /sys/power/wake_lock let android enter the early_suspend mode get cpuidle statistics on cpu0 et cpu1 in cpuidle/stateX/time : only state0 time is different from 0 Is it a normal behavior ? Regards, Vincent

14 years

RE: [PATCH] leds-lp5521: additional platform data and attributes

by Kim, Milo

For better readability, values of LP5521_REG_ENABLE register were redefined. Signed-off-by: Milo(Woogyom) Kim <milo.kim(a)ti.com> --- drivers/leds/leds-lp5521.c | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c index 8239319..3f7cfe8 100644 --- a/drivers/leds/leds-lp5521.c +++ b/drivers/leds/leds-lp5521.c @@ -261,8 +261,7 @@ static int lp5521_configure(struct i2c_client *client) /* Set engines are set to run state when OP_MODE enables engines */ ret |= lp5521_write(client, LP5521_REG_ENABLE, - LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM | - LP5521_EXEC_RUN); + LP5521_ENABLE_RUN_PROGRAM); /* enable takes 500us. 1 - 2 ms leaves some margin */ usleep_range(1000, 2000); @@ -313,8 +312,7 @@ static int lp5521_detect(struct i2c_client *client) int ret; u8 buf; - ret = lp5521_write(client, LP5521_REG_ENABLE, - LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM); + ret = lp5521_write(client, LP5521_REG_ENABLE, LP5521_ENABLE_DEFAULT); if (ret) return ret; /* enable takes 500us. 1 - 2 ms leaves some margin */ @@ -322,7 +320,7 @@ static int lp5521_detect(struct i2c_client *client) ret = lp5521_read(client, LP5521_REG_ENABLE, &buf); if (ret) return ret; - if (buf != (LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM)) + if (buf != LP5521_ENABLE_DEFAULT) return -ENODEV; return 0; -- 1.7.4.1 -----Original Message----- From: Kim, Milo Sent: Friday, January 06, 2012 11:20 AM To: 'linux-kernel(a)vger.kernel.org'; 'rpurdie(a)rpsys.net' Cc: 'linaro-dev(a)lists.linaro.org'; 'milo.kim(a)ti.com' Subject: [PATCH] leds-lp5521: additional platform data and attributes * Changes of lp5521_platform_data > 'update_config' is added > 'name' is added Value of CONFIG register(Addr 08h) and name of led channels are dependant on the project. So these fields have been added in lp5521_platform_data. > led pattern data lp5521 has autonomous operation mode without external control. This patch includes how to configure the led patterns and load them. * Additional led class device attributes : delay_on, delay_off, blink For supporting blink mode, 3 attributes have been updated. * Additional i2c device attribute : led_pattern Platform specific led pattern can be loaded via the user-space. * Base kernel version : 3.0.9 Signed-off-by: Milo(Woogyom) Kim <milo.kim(a)ti.com> --- Documentation/leds/leds-lp5521.txt | 60 ++++++++++ drivers/leds/leds-lp5521.c | 222 +++++++++++++++++++++++++++++++++--- include/linux/leds-lp5521.h | 25 ++++ 3 files changed, 289 insertions(+), 18 deletions(-) diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index c4d8d15..b0d6abe 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -3,6 +3,7 @@ Kernel driver for lp5521 * National Semiconductor LP5521 led driver chip * Datasheet: http://www.national.com/pf/LP/LP5521.html + or http://www.ti.com/product/lp5521 Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com) @@ -43,17 +44,23 @@ Format: 10x mA i.e 10 means 1.0 mA example platform data: Note: chan_nr can have values between 0 and 2. +Each channel can have own name. +If name field is not defined, the default name will be set to 'xxxx:channelN' +(XXXX : pdata->label or i2c client name, N : channel number) static struct lp5521_led_config lp5521_led_config[] = { { + .name = "red", .chan_nr = 0, .led_current = 50, .max_current = 130, }, { + .name = "green", .chan_nr = 1, .led_current = 0, .max_current = 130, }, { + .name = "blue", .chan_nr = 2, .led_current = 0, .max_current = 130, @@ -86,3 +93,56 @@ static struct lp5521_platform_data lp5521_platform_data = { If the current is set to 0 in the platform data, that channel is disabled and it is not visible in the sysfs. + +update_config : CONFIG register (ADDR 08h) +This value is platform-specific data. If NULL, the default value will be set. + +example) + +#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \ + LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ + LP5521_CLK_INT) + +static struct lp5521_platform_data lp5521_pdata = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_INT, + .update_config = LP5521_CONFIGS, +}; + +LED patterns : LP5521 has autonomous operation without external control. +Pattern data can be defined in the platform data. + +example) +/* Pattern : RGB(50,5,0) 500ms on, 500ms off, infinite loop */ +static u8 pattern_red[] = { + 0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static u8 pattern_green[] = { + 0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static struct lp5521_led_pattern board_led_patterns[] = { + { + .r = pattern_r, + .g = pattern_g, + .size_r = ARRAY_SIZE(pattern_r), + .size_g = ARRAY_SIZE(pattern_g), + }, +}; + +static struct lp5521_platform_data lp5521_platform_data = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_EXT, + .patterns = board_led_patterns, + .num_patterns = ARRAY_SIZE(board_led_patterns), +}; + +Then the predefined led pattern can be executed via the user-space. +To start the pattern #1, +# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern +(xxxx : i2c bus & slave address) +To end the pattern, +# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c index cc1dc48..8239319 100644 --- a/drivers/leds/leds-lp5521.c +++ b/drivers/leds/leds-lp5521.c @@ -80,23 +80,23 @@ /* Bits in ENABLE register */ #define LP5521_MASTER_ENABLE 0x40 /* Chip master enable */ #define LP5521_LOGARITHMIC_PWM 0x80 /* Logarithmic PWM adjustment */ +#define LP5521_EXEC_MASK 0xC0 #define LP5521_EXEC_RUN 0x2A - -/* Bits in CONFIG register */ -#define LP5521_PWM_HF 0x40 /* PWM: 0 = 256Hz, 1 = 558Hz */ -#define LP5521_PWRSAVE_EN 0x20 /* 1 = Power save mode */ -#define LP5521_CP_MODE_OFF 0 /* Charge pump (CP) off */ -#define LP5521_CP_MODE_BYPASS 8 /* CP forced to bypass mode */ -#define LP5521_CP_MODE_1X5 0x10 /* CP forced to 1.5x mode */ -#define LP5521_CP_MODE_AUTO 0x18 /* Automatic mode selection */ -#define LP5521_R_TO_BATT 4 /* R out: 0 = CP, 1 = Vbat */ -#define LP5521_CLK_SRC_EXT 0 /* Ext-clk source (CLK_32K) */ -#define LP5521_CLK_INT 1 /* Internal clock */ -#define LP5521_CLK_AUTO 2 /* Automatic clock selection */ +#define LP5521_EXEC_HOLD 0x00 +#define LP5521_ENABLE_DEFAULT \ + (LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM) +#define LP5521_ENABLE_RUN_PROGRAM \ + (LP5521_ENABLE_DEFAULT | LP5521_EXEC_RUN) /* Status */ #define LP5521_EXT_CLK_USED 0x08 +/* Blink mode */ +#define ALWAYS_OFF 0 + +/* Pattern Mode */ +#define PATTERN_OFF 0 + struct lp5521_engine { int id; u8 mode; @@ -112,6 +112,8 @@ struct lp5521_led { struct led_classdev cdev; struct work_struct brightness_work; u8 brightness; + int delay_on; + int delay_off; }; struct lp5521_chip { @@ -237,6 +239,7 @@ static void lp5521_init_engine(struct lp5521_chip *chip) static int lp5521_configure(struct i2c_client *client) { struct lp5521_chip *chip = i2c_get_clientdata(client); + u8 cfg = chip->pdata->update_config; int ret; lp5521_init_engine(chip); @@ -244,9 +247,12 @@ static int lp5521_configure(struct i2c_client *client) /* Set all PWMs to direct control mode */ ret = lp5521_write(client, LP5521_REG_OP_MODE, 0x3F); - /* Enable auto-powersave, set charge pump to auto, red to battery */ - ret |= lp5521_write(client, LP5521_REG_CONFIG, - LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT); + if (cfg) + ret |= lp5521_write(client, LP5521_REG_CONFIG, cfg); + else + ret |= lp5521_write(client, LP5521_REG_CONFIG, + LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | + LP5521_R_TO_BATT); /* Initialize all channels PWM to zero -> leds off */ ret |= lp5521_write(client, LP5521_REG_R_PWM, 0); @@ -533,13 +539,184 @@ static ssize_t lp5521_selftest(struct device *dev, return sprintf(buf, "%s\n", ret ? "FAIL" : "OK"); } +static void lp5521_clear_program_memory(struct i2c_client *cl) +{ + int i; + u8 rgb_mem[] = { + LP5521_REG_R_PROG_MEM, + LP5521_REG_G_PROG_MEM, + LP5521_REG_B_PROG_MEM, + }; + + for (i = 0; i < ARRAY_SIZE(rgb_mem); i++) { + lp5521_write(cl, rgb_mem[i], 0); + lp5521_write(cl, rgb_mem[i] + 1, 0); + } +} + +static void lp5521_write_program_memory(struct i2c_client *cl, + u8 base, u8 *rgb, int size) +{ + int i; + + if (!rgb || size <= 0) + return; + + for (i = 0; i < size; i++) + lp5521_write(cl, base + i, *(rgb + i)); + + lp5521_write(cl, base + i, 0); + lp5521_write(cl, base + i + 1, 0); +} + +static inline struct lp5521_led_pattern *lp5521_get_pattern + (struct lp5521_chip *chip, u8 offset) +{ + struct lp5521_led_pattern *pattern; + pattern = chip->pdata->patterns + (offset - 1); + return pattern; +} + +static void lp5521_run_led_pattern(int mode, struct lp5521_chip *chip) +{ + struct lp5521_led_pattern *ptn; + struct i2c_client *cl = chip->client; + u8 num_patterns = chip->pdata->num_patterns; + + if (mode > num_patterns || !(chip->pdata->patterns)) + return; + + if (mode == PATTERN_OFF) { + lp5521_write(cl, LP5521_REG_ENABLE, LP5521_ENABLE_DEFAULT); + usleep_range(1000, 2000); + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_DIRECT); + } else { + ptn = lp5521_get_pattern(chip, mode); + if (!ptn) + return; + + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_LOAD); + usleep_range(1000, 2000); + + lp5521_clear_program_memory(cl); + + lp5521_write_program_memory(cl, LP5521_REG_R_PROG_MEM, + ptn->r, ptn->size_r); + lp5521_write_program_memory(cl, LP5521_REG_G_PROG_MEM, + ptn->g, ptn->size_g); + lp5521_write_program_memory(cl, LP5521_REG_B_PROG_MEM, + ptn->b, ptn->size_b); + + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_RUN); + usleep_range(1000, 2000); + lp5521_write(cl, LP5521_REG_ENABLE, LP5521_ENABLE_RUN_PROGRAM); + } +} + +static ssize_t store_led_pattern(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct lp5521_chip *chip = i2c_get_clientdata(to_i2c_client(dev)); + unsigned long val; + int ret; + + ret = strict_strtoul(buf, 16, &val); + if (ret) + return ret; + + lp5521_run_led_pattern(val, chip); + + return len; +} + +static ssize_t show_delay_on(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + + return sprintf(buf, "%d\n", led->delay_on); +} + +static ssize_t store_delay_on(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long curr; + + if (strict_strtoul(buf, 0, &curr)) + return -EINVAL; + + led->delay_on = (int)curr; + + return len; +} + +static ssize_t show_delay_off(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + + return sprintf(buf, "%d\n", led->delay_off); +} + +static ssize_t store_delay_off(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long curr; + + if (strict_strtoul(buf, 0, &curr)) + return -EINVAL; + + led->delay_off = (int)curr; + + return len; +} + +static ssize_t store_blink(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long is_blink_set; + unsigned long on = led->delay_on; + unsigned long off = led->delay_off; + + if (strict_strtoul(buf, 0, &is_blink_set)) + return -EINVAL; + + if (!is_blink_set) + on = ALWAYS_OFF; + + led_blink_set(led_cdev, &on, &off); + + return len; +} + /* led class device attributes */ static DEVICE_ATTR(led_current, S_IRUGO | S_IWUSR, show_current, store_current); static DEVICE_ATTR(max_current, S_IRUGO , show_max_current, NULL); +static DEVICE_ATTR(delay_on, S_IRUGO | S_IWUSR, show_delay_on, store_delay_on); +static DEVICE_ATTR(delay_off, S_IRUGO | S_IWUSR, show_delay_off, + store_delay_off); +static DEVICE_ATTR(blink, S_IWUSR, NULL, store_blink); static struct attribute *lp5521_led_attributes[] = { &dev_attr_led_current.attr, &dev_attr_max_current.attr, + &dev_attr_delay_on.attr, + &dev_attr_delay_off.attr, + &dev_attr_blink.attr, NULL, }; @@ -558,6 +735,7 @@ static DEVICE_ATTR(engine1_load, S_IWUSR, NULL, store_engine1_load); static DEVICE_ATTR(engine2_load, S_IWUSR, NULL, store_engine2_load); static DEVICE_ATTR(engine3_load, S_IWUSR, NULL, store_engine3_load); static DEVICE_ATTR(selftest, S_IRUGO, lp5521_selftest, NULL); +static DEVICE_ATTR(led_pattern, S_IWUSR, NULL, store_led_pattern); static struct attribute *lp5521_attributes[] = { &dev_attr_engine1_mode.attr, @@ -567,6 +745,7 @@ static struct attribute *lp5521_attributes[] = { &dev_attr_engine1_load.attr, &dev_attr_engine2_load.attr, &dev_attr_engine3_load.attr, + &dev_attr_led_pattern.attr, NULL }; @@ -617,10 +796,16 @@ static int __devinit lp5521_init_led(struct lp5521_led *led, return -EINVAL; } - snprintf(name, sizeof(name), "%s:channel%d", - pdata->label ?: client->name, chan); led->cdev.brightness_set = lp5521_set_brightness; - led->cdev.name = name; + + if (pdata->led_config[chan].name) { + led->cdev.name = pdata->led_config[chan].name; + } else { + snprintf(name, sizeof(name), "%s:channel%d", + pdata->label ?: client->name, chan); + led->cdev.name = name; + } + res = led_classdev_register(dev, &led->cdev); if (res < 0) { dev_err(dev, "couldn't register led on channel %d\n", chan); @@ -749,6 +934,7 @@ static int lp5521_remove(struct i2c_client *client) struct lp5521_chip *chip = i2c_get_clientdata(client); int i; + lp5521_run_led_pattern(PATTERN_OFF, chip); lp5521_unregister_sysfs(client); for (i = 0; i < chip->num_leds; i++) { diff --git a/include/linux/leds-lp5521.h b/include/linux/leds-lp5521.h index fd548d2..c842527 100644 --- a/include/linux/leds-lp5521.h +++ b/include/linux/leds-lp5521.h @@ -26,23 +26,48 @@ /* See Documentation/leds/leds-lp5521.txt */ struct lp5521_led_config { + char *name; u8 chan_nr; u8 led_current; /* mA x10, 0 if led is not connected */ u8 max_current; }; +struct lp5521_led_pattern { + u8 *r; + u8 *g; + u8 *b; + u8 size_r; + u8 size_g; + u8 size_b; +}; + #define LP5521_CLOCK_AUTO 0 #define LP5521_CLOCK_INT 1 #define LP5521_CLOCK_EXT 2 +/* Bits in CONFIG register */ +#define LP5521_PWM_HF 0x40 /* PWM: 0 = 256Hz, 1 = 558Hz */ +#define LP5521_PWRSAVE_EN 0x20 /* 1 = Power save mode */ +#define LP5521_CP_MODE_OFF 0 /* Charge pump (CP) off */ +#define LP5521_CP_MODE_BYPASS 8 /* CP forced to bypass mode */ +#define LP5521_CP_MODE_1X5 0x10 /* CP forced to 1.5x mode */ +#define LP5521_CP_MODE_AUTO 0x18 /* Automatic mode selection */ +#define LP5521_R_TO_BATT 4 /* R out: 0 = CP, 1 = Vbat */ +#define LP5521_CLK_SRC_EXT 0 /* Ext-clk source (CLK_32K) */ +#define LP5521_CLK_INT 1 /* Internal clock */ +#define LP5521_CLK_AUTO 2 /* Automatic clock selection */ + struct lp5521_platform_data { struct lp5521_led_config *led_config; u8 num_channels; u8 clock_mode; + u8 update_config; int (*setup_resources)(void); void (*release_resources)(void); void (*enable)(bool state); const char *label; + struct lp5521_led_pattern *patterns; + u8 num_patterns; }; #endif /* __LINUX_LP5521_H */ -- 1.7.4.1 Best Regards Milo (Woogyom) Kim Texas Instruments Incorporated

14 years

[PATCH v4 0/6] common clk framework

by Mike Turquette

From: Mike Turquette <mturquette(a)ti.com> The common clk framework is an attempt to define a generic struct clk which most platforms can use to build a clk tree and perform a set of well-defined operations. The previous patchset, v3, can be found at, http://article.gmane.org/gmane.linux.kernel/1218622 New stuff in v4: * clk rate change notifiers * clk debug info via debugfs (instead of sysfs) * lots of bug fixes Stuff that is known to be missing in v4: * basic mux and divider clk types * fix for migrating clk_prepare_count/clk_enable_count in clk_set_parent * minor rework comments from v3 * Documentation/clk.txt needs love All of the mising items above will be rolled into v5 ASAP. I wanted to go ahead and push out the new notifier changes for review and gather comments on those since those were a big gap in the v3 patchset. Paul W. also had some good comments about the greater clk API, and the opportunity to fix some of that stuff while this patchset is still under discussion. I didn't address those here because they require more thought, and more comments from reviewers. Finally, OMAP4 support for the common struct clk will be posted immediately after this patch series to LAKML and LOML, along with some hack patches that show how to use the recursive clk_set_rate for propagating rate changes up the tree for CPUfreq and how to use the new clk rate change notifiers in a driver. Mike Turquette (6): clk: Kconfig: add entry for HAVE_CLK_PREPARE Documentation: common clk API clk: introduce the common clock framework clk: introduce rate change notifiers clk: basic gateable and fixed-rate clks clk: export the clk tree topology to debugfs Documentation/clk.txt | 312 +++++++++++++++ drivers/clk/Kconfig | 23 ++ drivers/clk/Makefile | 4 +- drivers/clk/clk-basic.c | 208 ++++++++++ drivers/clk/clk.c | 992 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/clk.h | 230 +++++++++++- 6 files changed, 1765 insertions(+), 4 deletions(-) create mode 100644 Documentation/clk.txt create mode 100644 drivers/clk/clk-basic.c create mode 100644 drivers/clk/clk.c -- 1.7.5.4

14 years

[Activity] Power Management WG Weekly Status report for week ending 2012-01-13

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report & meeting minutes for the Power Management working group for the week ending 2012-01-13 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2012-01-12 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2012-01-11 == Summary == (For details, see the Weekly Status Report and Meeting Minutes ) * Scheduler mini-summit * Setting for a scheduler mini-summit at Connet, Paul McKenney and Vincent Guittot will moderate. * Thermal Driver * Rob submitted the thermal driver patch for i.MX6 Freescale. Based on feedback, he will fix and make more extensive tests on the next submission. * Amit Daniel working on use the temperature information in thermal layer to generate some useful information like temperature drop per cooling state. Amit has submitted proposal for thermal framework discussion in ELC. * Cpuidle * Daniel is moving cpuilde drivers to drivers directory, he discussed this with Russel and Arnd and agreed on how to do it. * Current major area of work on cpuidle * Moving all cpuidle drivers from sub-arch directory to driver directory * Cleaning up Arm cpuidle and make a generic common cpuidle driver framework, so all platforms can use it. * Rob/Daniel working on moving i.mx and st-e cpuidle drivers to use the new common cpuidle. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years

[Activity] Kernel WG Weekly Status report for week ending 2012-01-13

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status & Individual Activity reports for the kernel working group for the week ending 2012-01-13 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2012-01-12 <https://wiki.linaro.org/WorkingGroups/Kernel/Status/2012-01-12> == Individual Activity Report == https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2012-01-06 <https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2012-01-06> == Summary == (For more details, please see the Status report or the Individual Activity report above) * Sub-teams The KWG has re-organized into sub-teams, links to the teams' pages (which are still under construction) can be reached from https://wiki.linaro.org/WorkingGroups/Kernel. * Kernel Release Andrey Konvalov is handling the Linaro baseline kernel release from now on. He has a tracking branch setup (http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git)<about:blank> that is currently on 3.2 and has a number of 3.3 patches he will be merging for the 12.01 release including updates to DT, sched_mc, and pinmux. Expect a kernel release on Jan 19th. * Pinctrl * Linusw sent a pull request for the top of the pinctrl branch that has matured in linux-next to Torvalds * PXA is very mature and was merged on top of LinusW devel branch, but did not make it into this merge window. * Work on pinctrl binding to DT is progressing, extensive discussions on how to add DT binding for pinctrl drivers. * Device Tree * Submitted patch for a new lcd power control driver with device tree support. * Submitted device tree support patch for generic power domains. * Submitted device tree support patch for Samsung display controller. * Reviewed imx pinctrl patch series from Aisheng, and had some extensive discussion on how we should add DT binding for pinctrl drivers. * Android * Planning to submit patch queue that adds an android alarmtimer driver, which is mended to use the upstreamed alarmtimer code, to staging, * Submitted talk on Android kernel patch status for ELC * Sent a few iterations of the patches to evdev to allow monotonic timestamps to be used (required for ICS). * imx maintenance * Collected a number of imx tty/serial patches and sent them to Greg for 3.3 merge window. * Collected a couple of imx6 PM fixup patches from Eric Miao * Reviewed a number of imx6 related patches * Sent the clk-prepare series to fix mutex locking issue while moving, one step towards common-clk frame work * Sent a patch to use CHIPID register to detect soc between imx23 andimx28 * Tested the patch from Fabio Estevam adding audio support intomxs_defconfig Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years

[PATCH] mmc: use usleep_range() in mmc_delay()

by Dmitry Antipov

From f447d78db65c6675e69466e8ed08364ff065ac08 Mon Sep 17 00:00:00 2001 From: Dmitry Antipov <dmitry.antipov(a)linaro.org> Date: Wed, 21 Dec 2011 10:51:03 +0400 Subject: [PATCH] mmc: use usleep_range() in mmc_delay() --- drivers/mmc/core/core.h | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h index 14664f1..a77851e 100644 --- a/drivers/mmc/core/core.h +++ b/drivers/mmc/core/core.h @@ -47,12 +47,8 @@ void mmc_power_off(struct mmc_host *host); static inline void mmc_delay(unsigned int ms) { - if (ms < 1000 / HZ) { - cond_resched(); - mdelay(ms); - } else { - msleep(ms); - } + unsigned long us = ms * USEC_PER_MSEC; + usleep_range(us, us + 1000); } void mmc_rescan(struct work_struct *work); -- 1.7.7.4

14 years

linaro powertop doesn't work during initialization of ncurse

by Chanwoo Choi

Hi Amit, I used linaro powertop to check idle state on embedded board with EXYNOS4 series. I modified Makefile to use -lncurse instead of -lncursew and it was well operated on my board. - kernel : 2.6.36 - libncurse : libncurses5-dev But, same powertop binary doesn't work on new embedded board. When execute powertop, I faced one problem which stop powertop during initialization of ncurse in display.cpp. (init_display function) - kernel : 3.0 - libncurse : libncurses5-dev Does anyone have experience about it? Regards, Chanwoo Choi

14 years

Re: l-m-c hacking for UEFI

by Guilherme Salgado

Hi Ryan, I'm replying with a copy to linaro-dev@ as I believe adding support to UEFI into l-m-c will require a new hwpack format, which is something that needs discussion with a wider audience. On 11/01/12 13:51, Ryan Harkin wrote: > Hi Danilo, > > Ok, as we agreed, I've had a hack at the l-m-c script to produce an > image with UEFI instead of (or as well as) U-Boot. > > I've attached a diff for the changes I made. > > As I have no prior experience with this script, my changes are purely > for "demo" purposes. You're allowed to laugh at my basic perl > skills ;-) I hope you meant Python? Or did you include some perl code here as well? ;) > The changes are "generic", i.e. don't take into account that platforms > like Snowball have special "magic" for U-Boot and will probably need > special magic for UEFI. I expect "someone" will make those changes > whenever UEFI is developed for such platforms. Is it implemented for any of our supported platforms already? If not, do you have any idea when that might happen? > Also, the attached diff is only for hacking l-m-c. I haven't done > android-l-m-c, although I expect it's similar. And I haven't touched > the hwpack creation scripts so far. I'm writing this before I've gone through the diff, but I'd expect the hwpacks would have to grow some config options for that, which means a new hwpack format. If that's the case, we'll need to invite more people into the discussion and probably agree on what the new hwpack should look like before we change l-m-c. Sounds like a good candidate for a Connect session. :) > > So, what have I done? Quite simple, really: I've added a --bootloader > option to linaro-media-create. The option takes the values: none, > uboot, uefi or all. Default is "uboot" to mimic current behaviour. > > What is the desired behaviour of this option? > > none - no bootloader is copied to the disk image > uboot - only U-Boot images are copied to the disk image > uefi - only UEFI images are copied to the disk image > all - all bootloaders in the hwpack are copied to the disk image I'm wondering... do you have any use cases for the none and all options? > > If you specify a bootloader that doesn't exist in the hwpack, the script > will fail horribly. This is like current behaviour: if uboot is not in Right, but currently we know that the hwpacks for boards that use u-boot will include the u-boot binary, whereas with your changes users will have to first check that the bootloader they want is in the hwpack. I wonder if it wouldn't be better to make hwpacks include just one bootloader (whichever is chosen by the hwpack author)? > the hwpack, l-m-c will fail. I think this is only a problem for the > 'all' case. As a user, I'd expect the 'all' case to work if UEFI, > U-Boot or both were missing. But I'm not sure how best to fix that. > > How did I test it? > > - un-tar an existing hwpack > - add a 'uefi' directory with the files 'uefi.bin' and 'sec_uefi.bin' > - edit 'metadata' to add the UEFI keys: > UEFI=uefi/uefi.bin > SEC_UEFI=uefi/sec_uefi.bin > UEFI_IN_BOOT_PART=Yes > - re-tar it as before. > - run l-m-c > > > What next? I'd like you to review my changes and see if they make > sense. As mentioned earlier, I'd expect you to have a lot of criticisms > about the way I've implemented it, but I hope my example can help you > understand the direction I'd like the script to take. Your implementation seems straightforward to me, but given what I said above, I think there's not much point in discussing the implementation in l-m-c before we have agreed on what the new hwpack format should look like. > > Then, I need to work on the hwpack create scripts. I am a bit in the > dark with this as I don't know enough about hwpack creation. I believe > that to get the scripts to create a hwpack with UEFI inside, I am going > to have to package UEFI somehow. This is the area that I am not > familiar with: all of the packaging in the ARM LT has been done by > either Ricardo or Tixy. So, any links, docs, or hints would be > appreciated. A hwpack is just a bunch of .deb packages, some board-specific configs and the bootloader binary. In the case of UEFI, we'll probably only need a binary file to copy to the boot partition, so in theory there's no need for a .deb package. However, the hwpack creation script will need to get that from somewhere and given it already knows where to get .debs from, that might be easier. We do that for u-boot, but given its special nature, it doesn't need to be in the rootfs, so we just extract the actual bootloader from the .deb and put that in a fixed place for l-m-c to find. I imagine we'd do something similar for UEFI.

14 years

PulseAudio / ARM NEON

by Peter Meerwald

Hello, I've just posted some patches with ARM NEON code to the pulseaudio-discuss mail list (http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-January/01261…) -- this might be of interest to Linaro a stand-alone version of the code is in a Mercurial repo at http://pmeerw.net/hg/pa-neon -- feedback and testing welcome thanks, regards, p. -- Peter Meerwald +43-664-2444418 (mobile)

14 years

Linaro Kernel configs (was Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework)

by Amit Kucheria

On Thu, Jan 12, 2012 at 2:33 PM, Lee Jones <lee.jones(a)linaro.org> wrote: > On 12/01/12 12:20, Amit Kucheria wrote: >> On Thu, Jan 12, 2012 at 3:02 AM, Ricardo Salveti >> <ricardo.salveti(a)linaro.org> wrote: >>> On Wed, Jan 11, 2012 at 2:24 AM, Amit Kachhap <amit.kachhap(a)linaro.org> wrote: >>>> Hi Zach/Ricardo, >>>> >>>> All the thermal Kconfigs are enabled in >>>> https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig. >>> >>> Great, thanks. >>> >>> Guess we just need to make sure we're in sync with every LT tree >>> (android and package level too). >> >> In the LT-WG call yesterday, Lee wanted us to ping all the LT leads to >> make sure they had these configs enabled in the the kernel. Consider >> this a ping, guys :) >> >> Let us know if you need more information. > > Is this solely an Android thing, or do our Common Linux kernels require > them too? All our work is distro-agnostic. * sched_mc: should get enabled on all kernels since the core feature is now in mainline. * thermal management: should get enabled as we enable various SoCs in the Linaro kernel with SoC-specific drivers

14 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev