- linaro-kernel - lists.linaro.org

by john stultz

Was out sick weds, so not a super productive week. === Highlights === * Added EARLYSUSPEND to linaro+android defconfigs * Made final 11.11 linaro+android release * After being nudged by Thomas, sent out first draft of a large patchset reworking some of the timekeeping locking. * Reviewed and acked sched_clock overflow fix. * Helped with Android Image testing for 11.11 release * Submitted config fragment management script to akpm and it was included into the -mm tree. * Revised madvise volatile patchset a few times preping for lkml discussion. Got some good feedback that made me think it would be better to rework the patch to use fadvise instead of madvise. Started efforts to convert the interface over. === Plans === * Finish madvise->fadvise conversion, do one last cleanup and send to lkml. * Take another pass at the timekeeping locking for Thomas. * Push queued patches for 3.3 to Thomas. === Issues === * None

13 years, 6 months

1
0
0 0

[Activity] (Linus Walleij) 2011-11-12 - 2011-11-18

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Very active discussions around the pinctrl v2 patch sent sent out last week, much good feedback and slowly building consensus. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-pinprops-2011.11 * Refactored U300 GPIO to live in pinctrl as sibling to the U300 pinmux controller. Also implemented pin multiplexing and draft pin configuration interface (subject to change). This was done as a proof-of-concept that the pincontrol subsystem is good for something that exists out there. Will be sent out back-to-back with the pinconfig patch set. * Harvesting some fixes for pinctrl * Looked after the GPIO subsystem -rc fixes for Grant but haven't seen many patches, discussed a few non-rc patches. * A lot of discussion around the PL022 driver thread safety, led to the submission of the patch entitled: "spi/pl022: make the chip deselect handling thread safe" * Lots of mailing and reading trying to understand how to get my kernel.org git repo back online. === Plans === * Drive generalization of Nomadik GPIO by using the pinctrl framework. drivers/gpio/gpio-nomadik.c * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Pushed out the AB8500 HWMON driver, will try to address review comments. * Look into other Ux500 stuff in need of mainlining... === Issues === * Pretty much internal fuzz at my parent company due to re- organization. Thanks, Linus Walleij

13 years, 6 months

1
0
0 0

ACTIVITY (Rajendra Nayak) Nov 14 - Nov 18

by Rajendra Nayak

== Rajendra Nayak <rnayak> == === Highlights === * Posted an early RFC version of the omap pinmux driver. Working on improving it by adding missing pieces and based on review comments from Tony/Linus. * Posted omap serial dt support. Reworked to handle some shortcomings in the hmwod framework. Still, has missing low power (PM) support, which is currently implemented using platform func pointers. Need to work on a solution as people seem to dislike auxdata approach as its ugly. * Posted v5 of regulator core bindings. TWL regulator support still has dependencies on other (i2c/gpio/twl) OMAP dt patches. * Reworking TWL-smps support patches, based on the latest ones (post ELC discussions of Tero with Kevin/Benoit) sent across by Tero Kristo. === Plans === * Work on further improving the omap pinmux driver and add support for all OMAPs. * Rework any OMAP driver DT support patches.

13 years, 6 months

1
0
0 0

[PATCH] pinctrl: add a gpio and pinctrl driver for samsung io-pad controllers

by Thomas Abraham

Add a combined gpio and pinctrl io-pad driver for Samsung platforms. Signed-off-by: Thomas Abraham <thomas.abraham(a)linaro.org> --- This driver supports gpio, pinctrl and pinmux functionality. At present, all the possible pin groups and pin functions have not been added. This driver is designed to be reusable across all Samsung SoC's and when this implemtation is complete, the gpio driver in driver/gpio for samsung platforms can be phased out. Features like GPIO interrupt support and pin-config support are yet to be added. drivers/pinctrl/Kconfig | 6 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-samsung.c | 688 +++++++++++++++++++++++++++++++++++++ 3 files changed, 695 insertions(+), 0 deletions(-) create mode 100644 drivers/pinctrl/pinctrl-samsung.c diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index e17e2f8..55739d2 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -30,6 +30,12 @@ config PINMUX_U300 depends on ARCH_U300 select PINMUX +config PINCTRL_SAMSUNG + bool "Samsung pinctrl driver" + default y + depends on PLAT_SAMSUNG + select PINMUX + endmenu endif diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index bdc548a..463b934 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL) += core.o obj-$(CONFIG_PINMUX) += pinmux.o obj-$(CONFIG_PINMUX_SIRF) += pinmux-sirf.o obj-$(CONFIG_PINMUX_U300) += pinmux-u300.o +obj-$(CONFIG_PINCTRL_SAMSUNG) += pinctrl-samsung.o diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c new file mode 100644 index 0000000..0705a8d --- /dev/null +++ b/drivers/pinctrl/pinctrl-samsung.c @@ -0,0 +1,688 @@ +/* + * pin-controller/pin-mux/pin-config/gpio-driver for Samsung's SoC's. + * + * Copyright (c) 2011 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * Copyright (c) 2011 Linaro Ltd + * http://www.linaro.org + * + * Author: Thomas Abraham <thomas.abraham(a)linaro.org> + * + * This driver is divided into two main components, gpiolib subsystem interface + * and the pin-controller subsystem interface. This model help to better + * abstract the details of pad controller for all the Samsung SoC's. The driver + * is reusuable on all the Samsung SoC's, though the data that could get + * accumulated in this file could be daunting. + * + * The driver functions are kept as generic as possible such that they are + * usable across multiple Samsung SoC's. The driver data differentiates the + * operation of the driver for each SoC by describing the complete + * pad-controller structure to the driver and the generic driver code operates + * on the SoC specific driver data. The driver data also includes runtime data + * required for the operation of the driver. + * + * List of ToDo's: + * 1. Add GPIO Interrupt support. + * 2. Add external interrupt (wakeup) support. + * 3 Add power management support. + * 4 Add pin-config (pull up/down, driver strength) support. + * 5. Find a better way to populate data about pins and functions. + * 6. Add driver data, pins, groups, functions for all Samsung SoC's and test. + * + * 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 <linux/module.h> +#include <linux/platform_device.h> +#include <linux/io.h> +#include <linux/slab.h> +#include <linux/err.h> +#include <linux/pinctrl/pinctrl.h> +#include <linux/pinctrl/pinmux.h> +#include <linux/gpio.h> + +#include <plat/map-base.h> +#include <plat/map-s5p.h> + +#define DAT_REG 0x4 + +/** + * struct samsung_pin_bank: represent a controller pin-bank. + * @reg_offset: starting offset of the pin-bank registers. + * @pin_base: starting pin number of the bank. + * @nr_pins: number of pins included in this bank. + * @func_width: width of the function selector bit field. + * @irq_base: starting eint number of the bank. + */ +struct samsung_pin_bank { + unsigned int reg_offset; + unsigned int pin_base; + unsigned int nr_pins; + unsigned int func_width; + unsigned int irq_base; +}; + +/** + * struct samsung_pin_ctrl: represent a pin controller. + * @pin_banks: list of pin banks included in this controller. + * @nr_banks: number of pin banks. + * @base: starting system wide pin number. + * @nr_pins: number of pins supported by the controller. + * @label: for debug information. + */ +struct samsung_pin_ctrl { + struct samsung_pin_bank *pin_banks; + unsigned int nr_banks; + unsigned int base; + unsigned int nr_pins; + char *label; +}; + +/** + * struct samsung_pinctrl_drv_data: wrapper for holding driver data together. + * @virt_base: register base address of the controller. + * @ctrl: pin controller instance managed by the driver. + * @pctl: pin controller descriptor registered with the pinctrl subsystem. + * @pctl_dev: cookie representing pinctrl device instance. + * @pin_groups: list of pin groups available to the driver. + * @nr_groups: number of such pin groups. + * @pmx_functions: list of pin functions available to the driver. + * @nr_function: number of such pin functions. + * @gc: gpio_chip instance registered with gpiolib. + */ +struct samsung_pinctrl_drv_data { + void __iomem *virt_base; + struct samsung_pin_ctrl *ctrl; + struct pinctrl_desc *pctl; + struct pinctrl_dev *pctl_dev; + const struct samsung_pin_group *pin_groups; + unsigned int nr_groups; + const struct samsung_pmx_func *pmx_functions; + unsigned int nr_functions; + struct gpio_chip *gc; +}; + +/** + * struct samsung_pin_group: represent group of pins of a pinmux function. + * @name: name of the pin group, used to lookup the group. + * @pins: the pins included in this group. + * @num_pins: number of pins included in this group. + * @func: the function number to be programmed when selected. + */ +struct samsung_pin_group { + const char *name; + const unsigned int *pins; + const unsigned int num_pins; + unsigned int func; +}; + +/** + * struct samsung_pmx_func: represent a pin function. + * @name: name of the pin function, used to lookup the function. + * @groups: one or more names of pin groups that provide this function. + * @num_groups: number of groups included in @groups. + */ +struct samsung_pmx_func { + const char *name; + const char * const *groups; + const unsigned num_groups; +}; + +/* Note: The pin group list needs to be further populated */ +static unsigned int exynos4210_spi0_pins[] = { + EXYNOS4_GPB(0), EXYNOS4_GPB(1), EXYNOS4_GPB(2), EXYNOS4_GPB(3), +}; + +static unsigned int exynos4210_i2c0_pins[] = { + EXYNOS4_GPD1(0), EXYNOS4_GPD1(1), +}; + +static unsigned int exynos4210_sdhci0_pins[] = { + EXYNOS4_GPK0(0), EXYNOS4_GPK0(1), EXYNOS4_GPK0(2), EXYNOS4_GPK0(3), + EXYNOS4_GPK0(4), EXYNOS4_GPK0(5), EXYNOS4_GPK0(6), EXYNOS4_GPK0(7) +}; + +static unsigned int exynos4210_sdhci2_pins[] = { + EXYNOS4_GPK2(0), EXYNOS4_GPK2(1), EXYNOS4_GPK2(2), EXYNOS4_GPK2(3), + EXYNOS4_GPK2(4), EXYNOS4_GPK2(5), EXYNOS4_GPK2(6), EXYNOS4_GPK2(7) +}; + +static unsigned int exynos4210_i2s0_pins[] = { + EXYNOS4_GPZ(0), EXYNOS4_GPZ(1), EXYNOS4_GPZ(2), EXYNOS4_GPZ(3), + EXYNOS4_GPZ(4), EXYNOS4_GPZ(5), EXYNOS4_GPZ(6), EXYNOS4_GPZ(7) +}; + +static unsigned int exynos4210_pcm0_pins[] = { + EXYNOS4_GPZ(0), EXYNOS4_GPZ(1), EXYNOS4_GPZ(2), EXYNOS4_GPZ(3), + EXYNOS4_GPZ(4), EXYNOS4_GPZ(5), +}; + +#define PIN_GROUP(n, p, f) \ + { \ + .name = n, \ + .pins = p, \ + .num_pins = ARRAY_SIZE(p), \ + .func = f \ + } + +/* + * list of pin groups available for pin-controller[0] of Exynos4210. + * Note: This listed needs to be populated. + */ +static const struct samsung_pin_group exynos4210_pin_groups0[] = { + PIN_GROUP("spi0_grp", exynos4210_spi0_pins, 2), + PIN_GROUP("i2c0_grp", exynos4210_i2c0_pins, 2), +}; + +/* + * list of pin groups available for pin-controller[1] of Exynos4210. + * Note: This listed needs to be populated. + */ +static const struct samsung_pin_group exynos4210_pin_groups1[] = { + PIN_GROUP("sdhci0_grp", exynos4210_sdhci0_pins, 2), + PIN_GROUP("sdhci2_grp", exynos4210_sdhci2_pins, 2), +}; + +/* + * list of pin groups available for pin-controller[2] of Exynos4210. + * Note: This listed needs to be populated. + */ +static const struct samsung_pin_group exynos4210_pin_groups2[] = { + PIN_GROUP("i2s0_grp", exynos4210_i2s0_pins, 2), + PIN_GROUP("pcm0_grp", exynos4210_pcm0_pins, 2), +}; + +/* check if the selector is a valid pin group selector */ +static int samsung_list_groups(struct pinctrl_dev *pctldev, unsigned selector) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + if (selector >= drvdata->nr_groups) + return -EINVAL; + return 0; +} + +/* return the name of the group selected by the group selector */ +static const char *samsung_get_group_name(struct pinctrl_dev *pctldev, + unsigned selector) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + return drvdata->pin_groups[selector].name; +} + +/* return the pin numbers associated with the specified group */ +static int samsung_get_group_pins(struct pinctrl_dev *pctldev, + unsigned selector, const unsigned **pins, unsigned *num_pins) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + *pins = drvdata->pin_groups[selector].pins; + *num_pins = drvdata->pin_groups[selector].num_pins; + return 0; +} + +/* list of pinctrl callbacks for the pinctrl core */ +static struct pinctrl_ops samsung_pctrl_ops = { + .list_groups = samsung_list_groups, + .get_group_name = samsung_get_group_name, + .get_group_pins = samsung_get_group_pins, +}; + +static const char * const i2c0_grp[] = { "i2c0_grp" }; +static const char * const spi0_grp[] = { "spi0_grp" }; +static const char * const sdhci0_grp[] = { "sdhci0_grp" }; +static const char * const sdhci2_grp[] = { "sdhci2_grp" }; +static const char * const i2s0_grp[] = { "i2s0_grp" }; +static const char * const pcm0_grp[] = { "pcm0_grp" }; + +#define PMX_FUNC(n, g) \ + { \ + .name = n, \ + .groups = g, \ + .num_groups = ARRAY_SIZE(g), \ + } + +/* + * list of function names supported by the pinmux vertical. + * Note: All functions to be populated here. + */ +static const struct samsung_pmx_func exynos4210_pmx_functions0[] = { + PMX_FUNC("spi0", spi0_grp), + PMX_FUNC("i2c0", i2c0_grp), +}; + +/* + * list of function names supported by the pinmux vertical. + * Note: All functions to be populated here. + */ +static const struct samsung_pmx_func exynos4210_pmx_functions1[] = { + PMX_FUNC("sdhci0", sdhci0_grp), + PMX_FUNC("sdhci2", sdhci2_grp), +}; + +/* + * list of function names supported by the pinmux vertical. + * Note: All functions to be populated here. + */ +static const struct samsung_pmx_func exynos4210_pmx_functions2[] = { + PMX_FUNC("i2s0", i2s0_grp), + PMX_FUNC("pcm0", pcm0_grp), +}; + +/* check if the selector is a valid pin function selector */ +static int samsung_pinmux_list_funcs(struct pinctrl_dev *pctldev, + unsigned selector) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + if (selector >= drvdata->nr_groups) + return -EINVAL; + return 0; +} + +/* return the name of the pin function specified */ +static const char *samsung_pinmux_get_fname(struct pinctrl_dev *pctldev, + unsigned selector) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + return drvdata->pmx_functions[selector].name; +} + +/* return the groups associated for the specified function selector */ +static int samsung_pinmux_get_groups(struct pinctrl_dev *pctldev, + unsigned selector, const char * const **groups, + unsigned * const num_groups) +{ + struct samsung_pinctrl_drv_data *drvdata; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + *groups = drvdata->pmx_functions[selector].groups; + *num_groups = drvdata->pmx_functions[selector].num_groups; + return 0; +} + +/* + * given a pin number that is local to a pin controller, find out the pin bank + * and the register base of the pin bank. + */ +static void pin_to_reg_bank(struct gpio_chip *gc, unsigned pin, + void __iomem **reg, unsigned long *offset, + struct samsung_pin_bank **bank) +{ + struct samsung_pinctrl_drv_data *drvdata; + struct samsung_pin_bank *b; + + drvdata = dev_get_drvdata(gc->dev); + b = drvdata->ctrl->pin_banks; + + while (b->pin_base + b->nr_pins < pin) + b++; + + *reg = drvdata->virt_base + b->reg_offset; + *offset = pin - b->pin_base; + if (bank) + *bank = b; + + /* some banks have two config registers in a single bank */ + if (*offset * b->func_width > BITS_PER_LONG) + *reg += 4; +} + +/* enable or disable a pinmux function */ +static void samsung_pimux_setup(struct pinctrl_dev *pctldev, unsigned selector, + unsigned group, bool enable) +{ + struct samsung_pinctrl_drv_data *drvdata; + const unsigned int *pin; + unsigned long data, pin_offset, cnt; + struct samsung_pin_bank *bank; + void __iomem *reg; + unsigned int mask, shift; + + drvdata = pinctrl_dev_get_drvdata(pctldev); + pin = drvdata->pin_groups[group].pins; + + /* + * for each pin in the pin group selected, program the correspoding pin + * pin function number in the config register. + */ + for (cnt = 0; cnt < drvdata->pin_groups[group].num_pins; cnt++, pin++) { + pin_to_reg_bank(drvdata->gc, *pin - drvdata->ctrl->base, + &reg, &pin_offset, &bank); + mask = (1 << bank->func_width) - 1; + shift = pin_offset * bank->func_width; + + data = readl(reg); + data &= ~(mask << shift); + if (enable) + data |= drvdata->pin_groups[group].func << shift; + writel(data, reg); + } +} + +/* enable a specified pinmux by writing to registers */ +static int samsung_pinmux_enable(struct pinctrl_dev *pctldev, unsigned selector, + unsigned group) +{ + samsung_pimux_setup(pctldev, selector, group, true); + return 0; +} + +/* disable a specified pinmux by writing to registers */ +static void samsung_pinmux_disable(struct pinctrl_dev *pctldev, + unsigned selector, unsigned group) +{ + samsung_pimux_setup(pctldev, selector, group, false); +} + +/* list of pinmux callbacks for the pinmux vertical in pinctrl core */ +static struct pinmux_ops samsung_pinmux_ops = { + .list_functions = samsung_pinmux_list_funcs, + .get_function_name = samsung_pinmux_get_fname, + .get_function_groups = samsung_pinmux_get_groups, + .enable = samsung_pinmux_enable, + .disable = samsung_pinmux_disable, +}; + +/* gpiolib gpio_set callback function */ +static void samsung_gpio_set(struct gpio_chip *gc, unsigned offset, int value) +{ + void __iomem *reg; + unsigned long pin_offset, data; + + pin_to_reg_bank(gc, offset, &reg, &pin_offset, NULL); + data = readl(reg + DAT_REG); + data &= ~(1 << pin_offset); + if (value) + data |= 1 << pin_offset; + __raw_writel(data, reg + DAT_REG); +} + +/* gpiolib gpio_get callback function */ +static int samsung_gpio_get(struct gpio_chip *gc, unsigned offset) +{ + void __iomem *reg; + unsigned long pin_offset, data; + + pin_to_reg_bank(gc, offset, &reg, &pin_offset, NULL); + data = readl(reg + DAT_REG); + data >>= pin_offset; + data &= 1; + return data; +} + +/* register the pinctrl interface with the pinctrl subsystem */ +static int __init samsung_pinctrl_register(struct platform_device *pdev, + struct samsung_pinctrl_drv_data *drvdata) +{ + struct pinctrl_desc *ctrldesc = drvdata->pctl; + struct pinctrl_pin_desc *pindesc; + int pin; + + pindesc = devm_kzalloc(&pdev->dev, sizeof(*pindesc) * + drvdata->ctrl->nr_pins, GFP_KERNEL); + if (!pindesc) { + dev_err(&pdev->dev, "mem alloc for pin descriptors failed\n"); + return -ENOMEM; + } + ctrldesc->pins = pindesc; + ctrldesc->npins = drvdata->ctrl->nr_pins; + ctrldesc->maxpin = drvdata->ctrl->nr_pins; + + /* dynamically create the pindesc, ignore the name for pindesc */ + for (pin = 0; pin < ctrldesc->maxpin; pin++, pindesc++) + pindesc->number = pin + drvdata->ctrl->base; + + drvdata->pctl_dev = pinctrl_register(ctrldesc, &pdev->dev, drvdata); + if (!drvdata->pctl_dev) { + dev_err(&pdev->dev, "could not register pinctrl driver\n"); + return -EINVAL; + } + + return 0; +} + +/* register the gpiolib interface with the gpiolib subsystem */ +static int __init samsung_gpiolib_register(struct platform_device *pdev, + struct samsung_pinctrl_drv_data *drvdata) +{ + struct gpio_chip *gc; + int ret; + + gc = devm_kzalloc(&pdev->dev, sizeof(*gc), GFP_KERNEL); + if (!gc) { + dev_err(&pdev->dev, "mem alloc for gpio_chip failed\n"); + return -ENOMEM; + } + + drvdata->gc = gc; + gc->base = drvdata->ctrl->base; + gc->ngpio = drvdata->ctrl->nr_pins; + gc->dev = &pdev->dev; + gc->set = samsung_gpio_set; + gc->get = samsung_gpio_get; + gc->label = drvdata->ctrl->label; + gc->owner = THIS_MODULE; + ret = gpiochip_add(gc); + if (ret) { + dev_err(&pdev->dev, "failed to register gpio_chip %s, error " + "code: %d\n", gc->label, ret); + return ret; + } + + return 0; +} + +static int __devinit samsung_pinctrl_probe(struct platform_device *pdev) +{ + struct samsung_pinctrl_drv_data *drvdata; + struct resource *res; + int ret; + + drvdata = (struct samsung_pinctrl_drv_data *) + platform_get_device_id(pdev)->driver_data + (pdev->id); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "cannot find IO resource\n"); + return -ENOENT; + } + + res = request_mem_region(res->start, resource_size(res), + pdev->name); + if (!res) { + dev_err(&pdev->dev, "request for mem region failed\n"); + return -EBUSY; + } + + drvdata->virt_base = ioremap(res->start, resource_size(res)); + if (!drvdata->virt_base) { + dev_err(&pdev->dev, "ioremap failed\n"); + return -EINVAL; + } + + ret = samsung_gpiolib_register(pdev, drvdata); + if (ret) + return ret; + + ret = samsung_pinctrl_register(pdev, drvdata); + if (ret) + return ret; + + platform_set_drvdata(pdev, drvdata); + return 0; +} + +/* driver data for various samsung soc's */ +#ifdef CONFIG_CPU_EXYNOS4210 + +#define EXYNOS4_PIN_BANK(offset, __gpio) \ + { \ + .reg_offset = offset, \ + .pin_base = (__gpio##_START), \ + .nr_pins = (__gpio##_NR), \ + .func_width = 4, \ + } + +/* pin banks of pin-controller 0 */ +static struct samsung_pin_bank exynos4210_pin_banks0[] = { + EXYNOS4_PIN_BANK(0x000, EXYNOS4_GPIO_A0), + EXYNOS4_PIN_BANK(0x020, EXYNOS4_GPIO_A1), + EXYNOS4_PIN_BANK(0x040, EXYNOS4_GPIO_B), + EXYNOS4_PIN_BANK(0x060, EXYNOS4_GPIO_C0), + EXYNOS4_PIN_BANK(0x080, EXYNOS4_GPIO_C1), + EXYNOS4_PIN_BANK(0x0A0, EXYNOS4_GPIO_D0), + EXYNOS4_PIN_BANK(0x0C0, EXYNOS4_GPIO_D1), + EXYNOS4_PIN_BANK(0x0E0, EXYNOS4_GPIO_E0), + EXYNOS4_PIN_BANK(0x100, EXYNOS4_GPIO_E1), + EXYNOS4_PIN_BANK(0x120, EXYNOS4_GPIO_E2), + EXYNOS4_PIN_BANK(0x140, EXYNOS4_GPIO_E3), + EXYNOS4_PIN_BANK(0x160, EXYNOS4_GPIO_E4), + EXYNOS4_PIN_BANK(0x180, EXYNOS4_GPIO_F0), + EXYNOS4_PIN_BANK(0x1A0, EXYNOS4_GPIO_F1), + EXYNOS4_PIN_BANK(0x1C0, EXYNOS4_GPIO_F2), + EXYNOS4_PIN_BANK(0x1E0, EXYNOS4_GPIO_F3), +}; + +#define EXYNOS4_PIN_BANK1(offset, __gpio) \ + { \ + .reg_offset = offset, \ + .pin_base = (__gpio##_START) - EXYNOS4_GPIO_J0_START,\ + .nr_pins = (__gpio##_NR), \ + .func_width = 4, \ + } + +/* pin banks of pin-controller 1 */ +static struct samsung_pin_bank exynos4210_pin_banks1[] = { + EXYNOS4_PIN_BANK1(0x000, EXYNOS4_GPIO_J0), + EXYNOS4_PIN_BANK1(0x020, EXYNOS4_GPIO_J1), + EXYNOS4_PIN_BANK1(0x040, EXYNOS4_GPIO_K0), + EXYNOS4_PIN_BANK1(0x060, EXYNOS4_GPIO_K1), + EXYNOS4_PIN_BANK1(0x080, EXYNOS4_GPIO_K2), + EXYNOS4_PIN_BANK1(0x0A0, EXYNOS4_GPIO_K3), + EXYNOS4_PIN_BANK1(0x0C0, EXYNOS4_GPIO_L0), + EXYNOS4_PIN_BANK1(0x0E0, EXYNOS4_GPIO_L1), + EXYNOS4_PIN_BANK1(0x100, EXYNOS4_GPIO_L2), + EXYNOS4_PIN_BANK1(0x120, EXYNOS4_GPIO_Y0), + EXYNOS4_PIN_BANK1(0x140, EXYNOS4_GPIO_Y1), + EXYNOS4_PIN_BANK1(0x160, EXYNOS4_GPIO_Y2), + EXYNOS4_PIN_BANK1(0x180, EXYNOS4_GPIO_Y3), + EXYNOS4_PIN_BANK1(0x1A0, EXYNOS4_GPIO_Y4), + EXYNOS4_PIN_BANK1(0x1C0, EXYNOS4_GPIO_Y5), + EXYNOS4_PIN_BANK1(0x1E0, EXYNOS4_GPIO_Y6), + EXYNOS4_PIN_BANK1(0xC00, EXYNOS4_GPIO_X0), + EXYNOS4_PIN_BANK1(0xC20, EXYNOS4_GPIO_X1), + EXYNOS4_PIN_BANK1(0xC40, EXYNOS4_GPIO_X2), + EXYNOS4_PIN_BANK1(0xC60, EXYNOS4_GPIO_X3), +}; + +#define EXYNOS4_PIN_BANK2(offset, __gpio) \ + { \ + .reg_offset = offset, \ + .pin_base = (__gpio##_START) - EXYNOS4_GPIO_Z_START,\ + .nr_pins = (__gpio##_NR), \ + .func_width = 4, \ + } + +/* pin banks of pin-controller 2 */ +static struct samsung_pin_bank exynos4210_pin_banks2[] = { + EXYNOS4_PIN_BANK2(0x000, EXYNOS4_GPIO_Z), +}; + +static struct samsung_pinctrl_drv_data exynos4210_pinctrl_drv_data[] = { + { + /* pin-controller instance 0 data */ + .ctrl = &(struct samsung_pin_ctrl) { + .pin_banks = exynos4210_pin_banks0, + .nr_banks = ARRAY_SIZE(exynos4210_pin_banks0), + .base = EXYNOS4_GPIO_A0_START, + .nr_pins = EXYNOS4_GPIO_J0_START - 1, + .label = "exynos4210-gpio-ctrl0", + }, + .pctl = &(struct pinctrl_desc) { + .name = "exynos4210_pinctrl", + .pctlops = &samsung_pctrl_ops, + .pmxops = &samsung_pinmux_ops, + .owner = THIS_MODULE, + }, + .pin_groups = exynos4210_pin_groups0, + .nr_groups = ARRAY_SIZE(exynos4210_pin_groups0), + .pmx_functions = exynos4210_pmx_functions0, + .nr_functions = ARRAY_SIZE(exynos4210_pmx_functions0), + }, { + /* pin-controller instance 1 data */ + .ctrl = &(struct samsung_pin_ctrl) { + .pin_banks = exynos4210_pin_banks1, + .nr_banks = ARRAY_SIZE(exynos4210_pin_banks1), + .base = EXYNOS4_GPIO_J0_START, + .nr_pins = EXYNOS4_GPIO_Z_START - + EXYNOS4_GPIO_J0_START, + .label = "exynos4210-gpio-ctrl1", + }, + .pctl = &(struct pinctrl_desc) { + .name = "exynos4210_pinctrl", + .pctlops = &samsung_pctrl_ops, + .pmxops = &samsung_pinmux_ops, + .owner = THIS_MODULE, + }, + .pin_groups = exynos4210_pin_groups1, + .nr_groups = ARRAY_SIZE(exynos4210_pin_groups1), + .pmx_functions = exynos4210_pmx_functions1, + .nr_functions = ARRAY_SIZE(exynos4210_pmx_functions1), + }, { + /* pin-controller instance 2 data */ + .ctrl = &(struct samsung_pin_ctrl) { + .pin_banks = exynos4210_pin_banks2, + .nr_banks = ARRAY_SIZE(exynos4210_pin_banks2), + .base = EXYNOS4_GPIO_Z_START, + .nr_pins = EXYNOS4_GPIO_Z_NR, + .label = "exynos4210-gpio-ctrl2", + }, + .pctl = &(struct pinctrl_desc) { + .name = "exynos4210_pinctrl", + .pctlops = &samsung_pctrl_ops, + .pmxops = &samsung_pinmux_ops, + .owner = THIS_MODULE, + }, + .pin_groups = exynos4210_pin_groups2, + .nr_groups = ARRAY_SIZE(exynos4210_pin_groups2), + .pmx_functions = exynos4210_pmx_functions2, + .nr_functions = ARRAY_SIZE(exynos4210_pmx_functions2), + }, +}; +#define EXYNOS4210_PCTRL_DRVDATA ((kernel_ulong_t)&exynos4210_pinctrl_drv_data) +#else +#define EXYNOS4210_PCTRL_DRVDATA (kernel_ulong_t)NULL +#endif /* CONFIG_CPU_EXYNOS4210 */ + +static struct platform_device_id samsung_pinctrl_driver_ids[] = { + { + .name = "exynos4-pinctrl", + .driver_data = EXYNOS4210_PCTRL_DRVDATA, + }, +}; + +static struct platform_driver samsung_pinctrl_driver = { + .probe = samsung_pinctrl_probe, + .id_table = samsung_pinctrl_driver_ids, + .driver = { + .name = "samsung-pinctrl", + .owner = THIS_MODULE, + }, +}; + +static int __init samsung_pinctrl_drv_register(void) +{ + return platform_driver_register(&samsung_pinctrl_driver); +} +postcore_initcall(samsung_pinctrl_drv_register); -- 1.6.6.rc2

13 years, 6 months

3
3
0 0

Linaro Kernel November 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our October 2011 development snapshot: linux-linaro-3.1-2011.11-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/linux-linaro-3.… The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.11-0 This kernel includes the following changes from the 2011.10 kernel: - The v3.1.1 stable kernel - LPAE support from Catalin Marinas - Samsung cpuidle work from Amit Kachhap - sched_mc optimization from Vincent Guittot - Fix for mmap greater than 2GB from Rob Herring A full change log against the 2011.09 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/CHANGELOG-linux… High Priority Known Issues: - None at this time This month's release is about a week early due to the upcoming Thanksgiving holidays in the US. If we find any major issues in the next few days, we will spin a new tarball. Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 6 months

1
0
0 0

[ACTIVITY] (Deepak Saxena) Nov 6-12

by Deepak Saxena

=== Highlights === * Wrote post for Linaro blog summarizing Linaro connect (http://www.linaro.org/linaro-blog/2011/11/09/kernel-working-group-a-linaro-…) * Started transferring new roadmap cards to launchpad blueprints * Started work on documenting proposed new kernel process * Working with Ohad upstream to understand status of rpmsg and what === Plans === * Finish writing up new kernel process * Release 11.11 kernel * Finish creating new blueprints * Work with Mounir on cleaning out old blueprints from 11.05 and 11.11 cycle * Find all my receipts and do expenses for ELC + LC * Create new roadmap cards === Travel/Time Off === * Tentatively taking next wed (11/23) off * Linaro holiday: Dec 26 - Jan 2

13 years, 6 months

1
0
0 0

ACTIVITY (Rajendra Nayak) Oct 31 - Nov 4

by Rajendra Nayak

== Rajendra Nayak <rnayak> == === Highlights === * Regulator core DT patches Acked by Mark. Some more minor comments from Olof, will need another final repost. * Initial omap hsmmc dt patches posted. Need more rework in cleaning up some of the legacy code from driver. * Mcspi/Ethernet dt patches validated, but with hack to make gpio_to_irq() work. Will post with proper implementation once Benoit fixes up the omap gpio adaptations. * Working on serial dt conversion, on top of the runtime changes /cleanup underway for omap serial driver. === Plans === * Repost regulator core binding series. * Rework/repost driver dt adaptations for omap mmc/serial/mcspi/eth * Start on pinmux driver for OMAP as communicated via Rypple. Tony Lindgren had plans of doing this, so need to syncup with him before I start off. * Work on basic OMAP5 support (test on emulator/simulator) using DT.

13 years, 6 months

2
1
0 0

[Activity] (Niklas Hernaeus) 2011-11-07 - 2011-11-13

by Niklas Hernaeus

== Niklas Hernaeus <nhe> == === General activity === * Prepared report of Linaro Connect for STE Competence group, security. To be held Monday 2011-11-14. * Preparing DT report for Knowledge sharing session. 20% done. * Preparing a Linaro collaboration tools session. (irc, mumble, etherpad, blueprints, rypple) 20% done. Date and form not set. * Sent out a lurking patch from Linus. Consequences not fully understood. * Found some issues with done dt support for uarts. Probably just need a kernel rebase. === Plans === * Make detailed plans for the work items. * Present Linaro Connect report for STE Competence group. * Make the dt uarts work again. * Start work on dt i2c. * Also, MMC must be included in the blueprints, somewhere at the top, below i2c.

13 years, 6 months

1
0
0 0

[ACTIVITY] (Shawn Guo) Week of Nov 7

by Shawn Guo

=== Device Tree === * imx5 board level DT series hit v3.2-rc1. * imx6 with DT support from the beginning hit v3.2-rc1. * Migrated mc13892 regulator to DT based Rajendra's series v4. Waiting for his series v5 to rebase and post mine. === Consolidation and cleanup === * Handed over imx pinctrl work to Dong Aisheng who has been assigned to pinctrl group for this work. And suggested we start from imx6 which needs pinctrl support badly. (imx6 becomes the priority for Freescale Landing Team) * Migrated imx6 clock to Mike's common clock series v2. Waiting for his series v3 to rebase and post my mine. * Sent a patch to remove imx_idle hook and use pm_idle instead to get imx arch_idle prepared for the global arch_idle cleanup coming later (suggested by Russell). === Misc === * Tested imx6 and mxs on v3.2-rc1. Collected a few fixing patches for v3.2-rc2. * Sent a patch to fix imx6 mmc error seen when mounting rootfs on SD/MMC card (reported by Dirk from Bosch). That is a temporary solution, and the issue should be eventually resolved by pinctrl support in a nice way. * Reported a v3.2-rc1 kernel issue. With CONFIG_PROVE_LOCKING enabled, a circular locking dependency warning is seen on both imx6 and imx5 with Linaro rootfs (nano, developer). === Plan === * Post mc13892 regulator DT patches * Post imx6 common clock patches * Look into Grant's clock DT bindings and try to play it with imx6 common clock support -- Regards, Shawn

13 years, 6 months

1
0
0 0

[ACTIVITY] (Thomas Abraham) 2011-11-07 - 2011-11-12

by Thomas Abraham

== Thomas Abraham <thomas-ab> == === Highlights === * Reviewed pinctrl driver and pinmux extensions. Completed a limited functionality driver for exynos4, will submit this for review. * Reviewed LinusW's pin configuration patch and checked compatibility for exynos4. === Plans === * Develop a complete pinctrl driver with all possible pinmux support. * Complete the device tree support for i2s driver.

13 years, 6 months

1
0
0 0

[ACTIVITY] (John Stultz) Nov 7th - 11th

by john stultz

Sort of a mix of things from this and the previous week. === Highlights === * Chased down a timekeeping bug in mult selection, pushed fix to Ingo * Pinged Michael Marek on status of merge_config.sh fragment tool. No response yet. Will send patch to akpm next week if I don't hear anything. * Worked on madvise VOLATILE ashmem alternative. Got first draft of the patch that seems to be working. Pinged Robert Love at Google to see if there were any unit tests available (sadly there aren't). Gotten some internal review from VM folks and need to address some style issues, then will hopefully sent to Robert for input and possibly publicly later. * Pinged Rafael on his wakelock related plans, after the Kernel Summit discussions. At his request I split out wakelock patches (credits to Andy Green for his Androidization tracking tree making this very easy) into an independent branch and submitted. * Generated background slide for Android Upstreaming work. * Enabled eCryptFS in Linaro+Android kernel defconfigs and released an the initial 11.11 linaro-android kernel. * Tried to chase down issues relating to 11.10 LEB release (from the linaro web page) being based on a 3.0 kernel, despite 3.1 branches being available. Seems there was a bit of miscommunication last cycle. Pressed to make sure this gets resolved early for 11.11. * Google got the Android kernel/common.git tree re-published. Latest branch is still 3.0 based, but there are some new patches there. * Took some time to work on sched_clock() mult overflows that are catching some systems at ~208 days of uptime. === Plans === * Work on additional madvise VOLATILE test cases, submit patch to rlove and possibly lkml. * Submit merge_config.sh to akpm * Submit a number of timekeeping cleanups for 3.3 to Thomas/Ingo * Try to submit sched_clock rework for discussion. * Tag 11.11. final linaro+android kernel === Issues === * None

13 years, 6 months

1
0
0 0

[ACTIVITY][weekly][linaro] (Dave Martin) 2011-10-24 - 2011-10-11

by Dave Martin

On Mon, Oct 24, 2011 at 12:31:29PM +0100, Dave Martin wrote: == Dave Martin <dmart> == === Activity Summary === Three weeks mostly taken up with preparing for, attending, and cleaning up after Linaro Connect * Investigated how to port vexpress to the proposed common struct clk. Looks straightforward. There appears to be no specfic blueprint for this yet(?) === Plans === * Finish Reviewing Pawel's patches and move Versatile Express DT work forward. * Finish collecting actions from Linaro Connect, map to blueprints and prioritise. === Work Items === https://blueprints.launchpad.net/linux-linaro/+spec/kernel-versatile-boad-d… * Review Pawel Moll's multi coretile support updates: INPROGRESS === Absences === (none planned)

13 years, 6 months

1
0
0 0

[Activity] (Linus Walleij) 2011-11-05 - 2011-11-11

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Harvesting some fixes for pinctrl * Sent out v2 of the pinctrl config patch set, blueprint duly updated: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-pinprops-2011.11 * Internal presentation of kernel WoW for our internal subsystem maintainers and management, agenda driven by the Snowball people. === Plans === * Grant requested me to look after patches for the GPIO subsystem for the next two weeks so that's what I'm gonna do. * Drive generalization of U300 and Nomadik GPIO by using the pinctrl framework. drivers/gpio/gpio-[nomadik|u300] * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Pushed out the AB8500 HWMON driver, will try to address review comments. * Look into other Ux500 stuff in need of mainlining... === Issues === * My last status mail *DISAPPEARED* from the Linaro Google mail account! However the mailing list archives house a copy: http://lists.linaro.org/pipermail/linaro-kernel/2011-November/000942.html Thanks, Linus Walleij

13 years, 6 months

1
0
0 0

ACTIVITY (Rajendra Nayak) Nov 7 - Nov 11

by Rajendra Nayak

== Rajendra Nayak <rnayak> == === Highlights === * Read through documentation, sample drivers, mailing list archives for pinctrl framework. Hacked up a basic pinmux-omap.c with minimal support for omap4 with very few functions/pin-groups defined. Needs some more work around enable/disable callbacks since OMAP pin-controller register organization is very different from existing ones which are adapted. Also in sync with Tony Lindgren (who did the existing omap-pinmux f/w) on the progress/approach. * Worked on v5 of core-regulator binding patches (fixing all comments from Olof). Will repost along with twl-regulator (including twl-smps support) after a rebase on the latest omap-i2c-twl dt adaptation patches which are under rework by Benoit Cousson. * Reworked some minor comments on omap-hsmmc dt adaptations by Olof. * Reworked omap-serial dt on top of latest serial runtime adaptation patches (rebased on 3.2-rc1). Need some more validation/cleanup before I post it out for review. === Plans === * Post an early pinmux omap support (with limited support on OMAP4 to begin with). hack up the existing auto-generation python scripts which auto-generate all OMAP pinmux data to generate the data in the new format needed by the pinctrl framework. * Repost existing series under rework, once the dependent series hit the list.

13 years, 6 months

1
0
0 0

[PATCH] totally untested attachment of device nodes to usb devices

by Grant Likely

Proof of concept, needs to be made compilable and add the unwind path on error and remove. Bodged-together-by: Grant Likely <grant.likely(a)secretlab.ca> --- Hi Deepak, Here's the code I hacked together on Friday. It would be useful to have someone take on this work and finish it so that device nodes can be attached to usb devices. g. drivers/usb/core/hub.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 96f05b2..bafd31d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1856,6 +1856,8 @@ fail: */ int usb_new_device(struct usb_device *udev) { + struct device_node *np = udev->bus->dev.of_node; + struct device_node *child; int err; if (udev->parent) { @@ -1864,6 +1866,17 @@ int usb_new_device(struct usb_device *udev) * sysfs power/wakeup controls wakeup enabled/disabled */ device_init_wakeup(&udev->dev, 0); + + /* Grab the device node for the hub */ + np = udev->parent->dev.of_node; + } + + /* Do we have a device tree node for this USB device? */ + if (np) { + for_each_child_of_node(child, np) { + if (value_of_reg_property(child) == udev->portnum) + udev->dev.of_node = of_node_get(child); + } } /* Tell the runtime-PM framework the device is active */ -- 1.7.5.4

13 years, 7 months

3
6
0 0

[ACTIVITY] (Thomas Abraham) 2011-11-02 - 2011-11-04

by Thomas Abraham

== Thomas Abraham <thomas-ab> == === Highlights === * Submitted rebased version of the samsung's sdhci driver device tree patches. * Started with device tree support for samsung's i2s audio interface driver. * Started looking into pinmux driver based on the pinctrl subsystem for samsung platforms. === Plans === * Submit next version of the sdhci driver dt patches with all comments addressed. * Complete the device tree support for i2s driver. * Complete the intial version of the pinmux driver for samsung platforms and submit for review.

13 years, 7 months

1
0
0 0

[Activity] (Linus Walleij) 2011-10-25 - 2011-11-04

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Torvalds has pulled the pinctrl subssystem for Linux v3.2. * Several other subsystems have also been pulled for 3.2, many patches created or signed-off by me have made their way into mainline due to this, including LP5521 and LM3530 LEDs, Nomadik I2C, DB8500 CPUfreq, MMC core and the PL180 MMCI driver, AB8500 Core, a bunch of DB8500 PRCMU patches, AB5500 driver, AB8500 GPADC, a few Integrator patches, PL022 SPI and of course a stack of Ux500 core patches. * All GPIO cleanups initially started in the Cambourne sprint in cooperation with Ben Dooks, have been pulled into Torvalds tree. * Fixed bugs in my own patches that have been pulled in by Torvalds, predominantly <mach/gpio.h> cleanup fallout and AB8500 MFD core. * Attended Linaro connect in Orlando. Mainly talking and planning, not much hands-on work here. === Plans === * Prepare a second patch for generic pin control. Shawn Guo and other developers are requesting this to be able to create complete pinctrl drivers targeted for 3.3. * Drive generalization of U300 and Nomadik GPIO by using the pinctrl framework. drivers/gpio/gpio-[nomadik|u300] * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Pushed out the AB8500 HWMON driver, will try to address review comments. * Mainline some ux500 U-Boot stuff so it can atleast boot the system. === Issues === * Some ST-Ericsson internal time-stealing as usual. Thanks, Linus Walleij

13 years, 7 months

1
0
0 0

[PATCH] totally untested attachment of device nodes to usb devices

by Grant Likely

Proof of concept, needs to be made compilable and add the unwind path on error and remove. Bodged-together-by: Grant Likely <grant.likely(a)secretlab.ca> --- Resend... I messed up Deepak's email addr. g. drivers/usb/core/hub.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 96f05b2..bafd31d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1856,6 +1856,8 @@ fail: */ int usb_new_device(struct usb_device *udev) { + struct device_node *np = udev->bus->dev.of_node; + struct device_node *child; int err; if (udev->parent) { @@ -1864,6 +1866,17 @@ int usb_new_device(struct usb_device *udev) * sysfs power/wakeup controls wakeup enabled/disabled */ device_init_wakeup(&udev->dev, 0); + + /* Grab the device node for the hub */ + np = udev->parent->dev.of_node; + } + + /* Do we have a device tree node for this USB device? */ + if (np) { + for_each_child_of_node(child, np) { + if (value_of_reg_property(child) == udev->portnum) + udev->dev.of_node = of_node_get(child); + } } /* Tell the runtime-PM framework the device is active */ -- 1.7.5.4

13 years, 7 months

1
0
0 0

Fwd: FYI: OpenID auth disabled on android-build.linaro.org

by Deepti Kalakeri

Hello, OpenID plugin usage has been disabled in ci.linaro.org due to some vulnerability detected with the plugin. Hence the Single Sig On option using your launchpad id wont work for now till it gets fixed. If you need to use ci.linaro.org services and need a way to login please create a new user on ci.linaro.org and mail me the details and I will give you appropriate access to the service. ---------- Forwarded message ---------- From: Paul Sokolovsky <paul.sokolovsky(a)linaro.org> Date: Fri, Oct 28, 2011 at 4:09 PM Subject: FYI: OpenID auth disabled on android-build.linaro.org To: linaro-android <linaro-android(a)linaro.org>, Alexander Sack < asac(a)linaro.org>, Danilo Šegan <danilo.segan(a)linaro.org>, Infrastructure < infrastructure(a)linaro.org> Hello, Due to suspected security issue, OpenID auth was disabed on android-build.linaro.org. OpenID was never recommended as auth means there, and instead username/passwd auth was recommended, so this change should not affect users. Please let me know if you have any issues. ETA for being enabled back is so far not known, Danilo Shegan tracks this issue. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Thanks and Regards, Deepti Infrastructure Team Member, 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

13 years, 7 months

2
1
0 0

Platform tests for kernel CI-loop

by Deepak Saxena

Hi all, I have created a blueprint [1] for connect to discuss the topic of platform level testing and want us to have some sense of what we want before going into a face to face discussion. I would like all the landing team leads to attend this session, so I've marked you as essential. The overall problem we are trying to solve is how do we ensure that hardware enablement (USB, MMC, etc) does not break across kernel versions. We've had several cases where a patch got merged into kernel.org that broke a device driver and we didn't catch it until just before our release. This causes us to scramble and reduces the quality of the work we're delivering to our members. With the CI loop in place, we now have the opportunity to catch these type of issues early on, before they even make it into the -rc kernels. My hope is that by the end of the summit session, we have a enough information to go back and develop a high level roadmap of test cases to deliver. The questions I'd like us to think about before the connect session include: 1) What are the different devices on each board that we want to test and how do we test them? We need to go through board by board and determine which I/O devices can be tested and come up with common methods to test them across all our existing platforms. One of the questions that comes up for me is what level of testing do we want? We can do simple discovery tests such as look for sysfs device nodes and poke at values in there or we can right small applications that test specific functionality (mounting block devices and running benchmark tests and also testing ioctls for example). 2) Who develops these tests? I think the answer to this is to have Landing Team engineers developing the board-specific tests with a KWG engineer assigned to coordinate overall direction of the work. 3) Do we integrate those tests into an existing framework (LTP for example) or develop a separate framework for these tests? Related to this question is whether some of the vendors will provide us test cases we can just pull into Lava? ~Deepak [1] https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-platform-…

13 years, 7 months

1
1
0 0

Key signing party for UDS/Linaro in Orlando

by Jorge O. Castro

On Mon, Oct 3, 2011 at 6:32 PM, Christian Robottom Reis <kiko(a)linaro.org> wrote: > On Mon, Oct 03, 2011 at 12:20:38PM -0700, Deepak Saxena wrote: >> Is there usually a key-signing at UDS? If not, should we organize a >> Linaro one? > > Copying Jorge. > > Yes, there's usually always a massive key-signing at UDS; Jorge, can you > get us details as to whether and when the Orlando one is? As far as I can tell there hasn't been an officially scheduled keysigning in a while, usually people organize one on their own after hours, however in light of recent events it might be prudent to organize one with Linaro on a certain day after sessions. CCing ubuntu-devel to see if anyone has plans/interest in getting this together.

13 years, 7 months

5
6
0 0

[ACTIVITY] (John Stultz) Oct 24th-28th

by john stultz

=== Highlights === * Resubmitted kconfig merge_config script to lkml * Submitted a number of clocksource cleanups to lkml * Had a number of alarmtimer cleanup patches merged into 3.2 merge window * Worked on further prototyping madvise ashmem interface * Heard from Paul that at Kernel Summit wakelocks were brought up and it sounds like they may be merged as is! Discussions on the list continue. * Submitted a documentation patch for the timekeeping core. * Made final 11.10 Linaro+Android kernel release * Spent a little time reviewing Neil Brown's userpsace pm deamon, but not as much as I was hoping for. * Worked on some virtualized testing environments to help with development and testing. * Setup linaro.org google+ account === Plans === * Linaro connect! * Continue working on ashmem alternative === Issues === * None

13 years, 7 months

1
0
0 0

Final linaro-android-3.1 updated for 11.10

by john stultz

Just wanted to announce that the final Linaro+Android-3.1 kernel is available. I've tagged it as: linux-linaro-3.1-2011.10-2-android-0 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase No changes other then updating to the latest linaro-3.1 updates. thanks -john

13 years, 7 months

1
0
0 0

Update on linaro-tracking-androidization for 3.2

by Andy Green

Hi - Linus released 3.1 a couple of days ago, I have archived the tracking androidization patchset with a pure vanilla 3.1 release basis here http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl… The tracking androidization tree has already moved on into Linus' new pre-3.2 basis territory http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl… There were big file layout refactors in the mainline networking stack that caused a lot of impact network / wireless related patches, some smaller adaptations needed in gadget related patches and a little bluetooth dust. Interestingly during the uplevel I noticed three patches (of ~470) had evidently managed to get upstream so far for 3.2 0419-ipv6-updates-to-privacy-addresses-per-RFC-4941.patch 0431-hid-debug-Show-application-usage-for-each-collection.patch 0432-hid-multitouch-Filter-collections-by-application-usa.patch I am updating the affected patches in linaro-androidization-tracking directly. I have already been automatically tagging each push, with, eg, "linaro-androidization-tracking-2011-10-25-18-24-CST", so there is a history of these rebase trees being kept. My plan after this is to perform a more aggressive squash on the refactored patchset (I would like to considerably reduce the number of "internal history" type patches, keeping the contributor patch logs in the squash patch's log) and moving to using just that, instead of continuing to run the patchset we started with and the refactored one simultaneously. I am testing this against OMAP4 Panda board, soon there will be more test coverage coming for the other LEBs supported by Linaro. We know already that some of the non-core Androidization features were broken in common-3.0 and remained broken in the starting point for this tree. Any patches to fix things like Broadcomm WLAN or whatever that we don't use at Linaro will be very welcome. However, we believe the all core Android features are working fine on this tree, since they result in a working Linaro Android rootfs for Panda (complete with PVR accelerated video). -Andy PS If anyone interested in this stuff is at Linaro Connect, feel free to ping me for a chat / beer

13 years, 7 months

1
0
0 0

[ACTIVITY] (Shawn Guo) Week of Oct 17

by Shawn Guo

=== Device Tree === * imx5 board level DT series is ready for v3.2 merge window. * Reviewed Rajendra's regulator DT series, and tested it with mc13892. Some issue with different level 'struct dev' was found and is being discussed. === Consolidation === * Reviewed Linus.W's pinctrl series about pin configuration part gave input there as far as imx iomuxc controller concerned. * Working on migrate imx6 clock to common clock v2 series from Mike Turquette === Misc === * The imx6q series has been pulled into arm-soc tree by Arnd for v3.2 merge window. * As suggested by Pengutronix, they want to get Sascha relieved from the burden of maintaining MXS (imx23 and imx28) sub-architecture. Since I brought the most of MXS core code to mainline, I stepped up for maintaining MXS. This will start when v3.2 merge window closes. I expect some amount of time will be spent on that at daily basis. * The book of Orlando travel was cancelled. -- Regards, Shawn

13 years, 7 months

4
7
0 0

Fwd: [ANN] Linaro CI Kernel Effort 2011.10

by Alexander Sack

FYI ---------- Forwarded message ---------- From: Deepti Kalakeri <deepti.kalakeri(a)linaro.org> Date: Tue, Oct 25, 2011 at 4:37 PM Subject: [ANN] Linaro CI Kernel Effort 2011.10 To: linaro-dev <linaro-dev(a)lists.linaro.org> Hello All, The Linaro Infrastructure team is pleased to announce the Continuous Integration (CI) efforts 2011.10. The Infrastructure Team is tasked to develop and maintain a jenkins based, versatile service run in the cloud that will drive the build part of the continuous integration loop for engineering components. Here are the highlights of this release: 1. A first iteration to support kernel maintainers to submit one time jobs for testing pull requests or their personal branches has been finished. Infrastructure team opens this service to a limited amount of pilot users to gather initial feedback. Please get in touch with me if you have similar needs. 2. Thanks to the validation team and special thanks to Michael Hudson, we now have One stop place for kernel CI tracking on LAVA dashboard is available where engineers can continuously monitor their kernel for build and runtime failures. The same is available @ http://validation.linaro.org/lava-server/kernel-ci-views/index. 3. ci.linaro.org service has been upgraded to now use jenkins 1.419 and EC2 plugin version 1.13. ci.linaro.org now aligns with jenkins version and EC2 plugin version with the one used for other infrastructure services (e.g. android-build). The future updates on the same will now on be coordinate across all such similar linaro infrastructure services. 4. Extended the kernel CI effort by supporting the daily build for Packaged Linux-linaro 3.0 and Linux-linaro 3.1 kernels for imx51, panda, vexpress. Packaged Linux-linaro 3.0 is tested on panda, beagle boards, while Linux-linaro 3.1 kernels is tested on panda board in the LAVA lab. 5. The release fixes Bug 860556 "CI kernel fails to reboot successfully". Known issues: CI kernels causing many "Illegal Instruction"s. Initial investigations done for this bug hints that this error might be occurring when we have a non-thumb2 kernel interacting with a thumb2 user space. Here is the link for further details on the bug and the steps to reproduce the same. https://bugs.launchpad.net/linaro-ci/+bug/859473 Any help to fix this would be appreciated. If you are interested in trying out this service or if you have a kernel tree/defconfig that you would like to be continuously built on Linaro CI and tested in Linaro's LAVA lab, please get in touch with me and the infrastructure team, to discuss your steps to get started. Detailed information on ci.linaro.org is available at + https://wiki.linaro.org/Platform/Infrastructure/LinaroCI Details and background on the CI build service and how to request a new job at + https://wiki.linaro.org/Platform/Infrastructure/LinaroCI -- Thanks and Regards, Deepti Infrastructure Team Member, 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(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 7 months

1
0
0 0

Enabling THUMB2 kernel config option

by Deepti Kalakeri

Hello All, I have a need to enable thumb2 kernel option for kernel built using omap2plus_defconfig. Hence I am trying to find a mechanism to automatically enable the thumb2 kernel config option. I have tried adding the CONFIG_THUMB2_KERNEL=y option to the .config file by 1) Appending it to the end of the .config using the echo CONFIG_THUMB2_KERNEL=y >> output_dir/.config 2) By replacing the CONFIG_ARM_THUMB=y with CONFIG_THUMB2_KERNEL=y option using the sed -ie 's/CONFIG_ARM_THUMB=y/CONFIG_THUMB2_KERNEL=y/g' output_dir/.config I follow this with the make oldconfig for ex: yes "" | make ARCH=arm O=output_dir KERNELVERSION=3.0.5-758-g051c523-omap2plus-linaro-omap KERNELRELEASE=3.0.5-758-g051c523-omap2plus-linaro-omap CROSS_COMPILE=arm-linux-gnueabi- oldconfig Both the above mechanisms work, but once I run oldconfig the .config is getting overwritten and it gets back to the old state. I am sure there is something which I am missing. Can you let me know the exact steps to overwrite the .config file. 1) I want to be able to overwrite the THUMB option with THUMB2 or add the THUMB2 option ( if existence of both THUMB and THUMB2 in the .config is permissible) 2) What would happen if both the CONFIG_ARM_THUMB=y and CONFIG_THUMB2_KERNEL=y options are present in the .config. Would the kernel be built with CONFIG_ARM_THUMB=y or CONFIG_THUMB2_KERNEL=y ? Do you have any suggestions to enable the THUMB2 option in a non-interactive way ? -- Thanks and Regards, Deepti Infrastructure Team Member, 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

13 years, 7 months

5
8
0 0

[GIT PULL] Device tree patches for 3.1 linaro release

by Grant Likely

Hi Nico, Here are the DT patches that I've got queued up for 3.1 and some extras needed for basic device tree booting support. I've left out the zimage append stuff since I believe it is already in your tree. g. The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96: Linux 3.1 (2011-10-24 09:10:05 +0200) are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 devicetree/arm-linaro-3.1 Ben Dooks (2): OF: Add of_match_ptr() macro tty: use of_match_ptr() for of_match_table entry Grant Likely (10): devicetree: Add a registry of vendor prefixes devicetree: Document Qualcomm and Atmel prefixes Merge branch 'for-grant' of git://git.jdl.com/software/linux-3.0 into devicetree/next devicetree: fix build error on drivers/tty/serial/altera_jtaguart.c Merge commit 'v3.1' into devicetree/next Devicetree: Expand on ARM Primecell binding documentation arm/dt: omap3 basic device tree board support arm/dt: Add basic device tree support for mx51 and mx53 boards arm/dt: vexpress: add basic DT platform matching support dt: Linux dt usage model documentation Jamie Iles (1): dt: add helper to read 64-bit integers John Bonesio (1): dt: Add id to AUXDATA structure Nicolas Ferre (1): dt: Add empty of_match_node() macro Rajendra Nayak (1): dt: add empty dt helpers for non-dt build Rob Herring (4): MAINTAINERS: update devicetree maintainers of/irq: of_irq_find_parent: check for parent equal to child devicetree: Add ARM pl061 gpio controller binding doc devicetree: Add ARM pl022 spi controller binding doc Shawn Guo (3): dt: add of_alias_scan and of_alias_get_id serial/imx: add of_alias_get_id() reference back arm/dt: add versatile dtb build rules Stephen Warren (1): dt: add empty for_each_child_of_node, of_find_property Thomas Abraham (1): arm/dt: Add basic device tree support for smdkv310 board .../devicetree/bindings/arm/freescale.txt | 7 + Documentation/devicetree/bindings/arm/genesi.txt | 8 + .../devicetree/bindings/arm/primecell.txt | 4 +- Documentation/devicetree/bindings/arm/samsung.txt | 9 + .../devicetree/bindings/gpio/pl061-gpio.txt | 10 + .../devicetree/bindings/spi/spi_pl022.txt | 12 + .../devicetree/bindings/vendor-prefixes.txt | 40 ++ Documentation/devicetree/usage-model | 403 ++++++++++++++++++++ MAINTAINERS | 2 + arch/arm/boot/dts/exynos4-smdkv310.dts | 11 + arch/arm/boot/dts/genesi-efikamx.dts | 22 + arch/arm/boot/dts/genesi-efikasb.dts | 22 + arch/arm/boot/dts/isee-igep-v2.dts | 7 + arch/arm/boot/dts/isee-igep-v3.dts | 7 + arch/arm/boot/dts/mx51-babbage.dts | 22 + arch/arm/boot/dts/mx53-loco.dts | 22 + arch/arm/boot/dts/omap3-beagle.dts | 7 + arch/arm/boot/dts/omap3-overo.dts | 7 + arch/arm/boot/dts/omap4-panda.dts | 11 + arch/arm/boot/dts/vexpress.dts | 10 + arch/arm/mach-exynos4/Makefile.boot | 2 + arch/arm/mach-exynos4/mach-smdkv310.c | 6 + arch/arm/mach-mx5/Makefile.boot | 5 + arch/arm/mach-mx5/board-mx51_babbage.c | 6 + arch/arm/mach-mx5/board-mx51_efikamx.c | 6 + arch/arm/mach-mx5/board-mx51_efikasb.c | 6 + arch/arm/mach-mx5/board-mx53_loco.c | 5 + arch/arm/mach-omap2/Makefile.boot | 6 + arch/arm/mach-omap2/board-igep0020.c | 12 + arch/arm/mach-omap2/board-omap3beagle.c | 6 + arch/arm/mach-omap2/board-omap4panda.c | 6 + arch/arm/mach-omap2/board-overo.c | 6 + arch/arm/mach-versatile/Makefile.boot | 2 + arch/arm/mach-vexpress/Makefile.boot | 2 + arch/arm/mach-vexpress/v2m.c | 6 + drivers/of/base.c | 150 ++++++++ drivers/of/fdt.c | 6 +- drivers/of/irq.c | 14 +- drivers/of/pdt.c | 8 + drivers/of/platform.c | 7 + drivers/tty/serial/altera_jtaguart.c | 5 +- drivers/tty/serial/altera_uart.c | 4 +- drivers/tty/serial/imx.c | 11 +- drivers/tty/serial/uartlite.c | 4 +- include/linux/of.h | 41 ++ include/linux/of_platform.h | 7 +- 46 files changed, 956 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/freescale.txt create mode 100644 Documentation/devicetree/bindings/arm/genesi.txt create mode 100644 Documentation/devicetree/bindings/arm/samsung.txt create mode 100644 Documentation/devicetree/bindings/gpio/pl061-gpio.txt create mode 100644 Documentation/devicetree/bindings/spi/spi_pl022.txt create mode 100644 Documentation/devicetree/bindings/vendor-prefixes.txt create mode 100644 Documentation/devicetree/usage-model create mode 100644 arch/arm/boot/dts/exynos4-smdkv310.dts create mode 100644 arch/arm/boot/dts/genesi-efikamx.dts create mode 100644 arch/arm/boot/dts/genesi-efikasb.dts create mode 100644 arch/arm/boot/dts/isee-igep-v2.dts create mode 100644 arch/arm/boot/dts/isee-igep-v3.dts create mode 100644 arch/arm/boot/dts/mx51-babbage.dts create mode 100644 arch/arm/boot/dts/mx53-loco.dts create mode 100644 arch/arm/boot/dts/omap3-beagle.dts create mode 100644 arch/arm/boot/dts/omap3-overo.dts create mode 100644 arch/arm/boot/dts/omap4-panda.dts create mode 100644 arch/arm/boot/dts/vexpress.dts -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

13 years, 7 months

2
1
0 0

[ACTIVITY][weekly][linaro] (Dave Martin) 2011-10-17 - 2011-10-21

by Dave Martin

== Dave Martin <dmart> == === Activity Summary === * holiday === Plans === Move Versatile Express DT patches forward Follow up on any feedback to AMBA module alias patches. Prepare for Linaro Connect * Schedule Versatile Express image deployment blueprint * Follow up on kernel CI loop blueprint status Prompt for further feedback on minor Thumb-2 randconfig issues: * Fixing some Thumb-2 related randconfig errors reported by Arnd: * pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for feedback (probably needs a Marvell expert to comment) * tegra2 uses non-Thumb-2-compatible code: waiting for feedback from Colin Cross. === Work Items === (none this week) === Absences === (none planned)

13 years, 7 months

1
0
0 0

ACTIVITY (Rajendra Nayak) Oct 10 - 14

by Rajendra Nayak

== Rajendra Nayak <rnayak> == === Highlights === * Reposted v2 of regulator dt support. Split the series to remove dependencies with omap i2c-twl dt conversions. Need to figure out how (if at all) to pass the linux specific regulator parameters via dt. latest patches can be found here git://gitorious.org/omap-pm/linux.git for-dt/regulator * The split series to convert twl-regulator to use dt can be found here git://gitorious.org/omap-pm/linux.git for-dt/regulator-i2c-twl Will repost after the i2c-twl repost from Benoit. * omap-hsmmc dt conversion completed and can be found here git://gitorious.org/omap-pm/linux.git for-dt/regulator-i2c-twl-mmc The series has dependencies on the above regulator series. Will post with the dependent series. * Adapted the omap-smps driver (originally done by Tero Kristo) to dt. Patches can be found here git://gitorious.org/omap-pm/linux.git for-dt/regulator-i2c-twl-smps Discussions on-going with Benoit/Kevin if this driver should be merged with the existing twl-regulator driver. * Kick started everyone in the team @TI with a presentation/status on DT on OMAP. === Plans === * Post all patches under development, taking care of dependencies. * Adapt spi/ethernet needed for basic NFS based boot, since lot of developers use NFS within TI. * Work on basic OMAP5 support (test on emulator/simulator) using DT.

13 years, 7 months

1
1
0 0

[Activity] (Linus Walleij) 2011-10-18 - 2011-10-24

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Maturing pinctrl core and pinmux in linux-next, answering late review comments and merging smaller patches. Latest finetuing iteration is v10. It is part of linux-next and I don't expect any more changes before the merge window. Drivers for U300 and SirfPrimaII is included. http://marc.info/?l=linux-kernel&m=131850357826490&w=2 * First patch implementing the basics of generic pin control was posted, iterating. http://marc.info/?l=linux-kernel&m=131914553520401&w=2 * Reviewed Stephen Warren's presentation of pinctrl for Prague. * Pushed out the AB8500 HWMON driver, will try to address review comments. === Plans === * Let pin control core and pinmux mature in -next and I expect to issue a pull request to Torvalds in the coming merge window * Working on generic pin control: * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Drive generalization of U300 and Nomadik GPIO by using the pinctrl framework * Mainline some ux500 U-Boot stuff so it can atleast boot the system. === Issues === * Some internal time-stealing as usual, a bit worse last week than usual so working a bit more from home this week to mitigate the effect. Thanks, Linus Walleij

13 years, 7 months

1
0
0 0

[ACTIVITY] (John Stultz) Oct 17th-21st

by john stultz

=== Highlights === * Merged compilation fixes from Bero and Agnus that were noticed by Eric * Released the freeze Linaro+Android kernel * After discussions with Niel Brown, came up with an idea for doing a wakelock alternate implementation in userspace. * Stalled work on the scheduler based timer freezer and starting work trying to prototype wakelock userspace daemon. * Booked travel * Worked with Dave Hansen on issues related to the Ashmem alternative prototype. * Scratched up summary of the linaro+android kernel workflow * Bit of infrastructure week, updating various systems with Ubuntu 11.10 in prep for Linaro Connect. === Plans === * Final 11.10 Linaro+Android kernel release * Review Neil Brown's userpsace pm deamon * Continue working on userspace wakelockd * Continue looking at ashmem alternative === Issues === * None

13 years, 7 months

1
0
0 0

linaro-android-3.1 tree updated!

by john stultz

Just wanted to announce that an updated Linaro+Android-3.1 kernel is available. I've tagged it as: linux-linaro-3.1-2011.10-1-android-0 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase Includes: * Fixes for compile issues found by Eric from Bero and Agnus. * Updates from Linaro-3.1 kernel. thanks! -john

13 years, 7 months

1
0
0 0

Linaro Kernel October 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our October 2011 development snapshot: linux-linaro-3.1-2011.10-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.10/+download/linux-linaro-3.… The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.10-1 In addition to an update to the 3.1 (-rc10) kernel, this kernel includes the following changes that are queued up for 3.2: - An EHCI slowdown workaround from Ming Lei - Thumb-2 undef handling fix for multi-CPU kernels from Dave Martin - ARM cpu topology definition from Vincent Guittot - RMK's devel-stable branch from last week that contains (among others): - Runtime consistent dma size init from Tixy - boot_params to atag_offset transition froma Nicolas Pitre - ARM pmu/perf updates from Will Deacon - The ability to append a DT to zImage from Nicolas Pitre - The ARM kprobes test infrastructure from Tixy - Suspend/resume consolidation and cleanups from RMK - cpu pm notifiers on ARM from Colin Cross A full change log against the 2011.09 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.10/+download/CHANGELOG-linux… High Priority Known Issues: - We have seen issues with boards not rebooting in our CI lab but so far Nicolas has been unable to reproduce it on his systems and we've not seen any reports of this on upstream 3.1-rc trees. Please download and test the kernel on your platforms and add notes to the following LP bug if you are able to reproduce this: https://bugs.launchpad.net/linaro-ci/+bug/860556 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 7 months

4
7
0 0

Which kernel version fo 11.10?

by Jon Medhurst (Tixy)

Do we know yet which kernel version we are targeting for the Linaro 11.10 release? -- Tixy

13 years, 7 months

7
8
0 0

[Activity] (Linus Walleij) 2011-10-11 - 2011-10-17

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Maturing pinctrl core and pinmux in linux-next, answering late review comments and merging smaller patches. Latest finetuing iteration is v10. It is part of linux-next and I don't expect any more changes before the merge window. http://marc.info/?l=linux-kernel&m=131850357826490&w=2 * Started to discuss generic pin control issues with Stephen Warren. * Discussing and reviewing some patches regarding the IIO ADC portions as IIO wants to move out of staging. * Samuel Ortiz merged say half of the PRCMU patches, we need to consolidate PRCMU infrastructure to merge more ux500 stuff. Fair enough. * Try to mainline some stuff. Harder than it seems, pushed out some SPI/PL022, AB8500 core, AB8500 RTC (after long calibration discussion), COH901327 watchdog. * Git tglx ACK for the smp_twd rescaling patch we all so badly need. However it's still pending in Russell's patch tracker. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6956/3 === Plans === * Let pin control core and pinmux mature in -next and I expect to issue a pull request to Torvalds in the coming merge window * Working on generic pin control: * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Drive generalization of U300 and Nomadik GPIO by using the pinctrl framework * Mainline some ux500 U-Boot stuff so it can atleast boot the system. === Issues === * Some internal time-stealing as usual, mostly for direct advice on things like MMC and runtime PM. Thanks, Linus Walleij

13 years, 7 months

1
0
0 0

[ACTIVITY] (John Stultz) Oct 10th-14th

by john stultz

=== Highlights === * Merged the initial Linaro-3.1 11.10 kernel with the omapzoom p-common-3.1 branch and pushed out the linaro-android-3.1 branch. * Re-merged Linaro-3.1 11.10 kernel with Andy Green's android tracking tree, and pushed out an updated linaro-android-3.1 branch. * Merged defconfig changes from Vishal to enable UVC across all boards. * Continued working on my sched-class based timer-freezing approach to power managment. * Pinged Amit Kachhap on ARM powertop issues. * Spurred by some of the recent discussion we've been having, Rafael (the PM maintainer) submitted his own proposal for a wakelock alternative. I reviewed and commented on some of the issues with the approach, and hope to see his proposal move forward. * Pinged Collin Cross about cgroup patches in the Android tree. Apparently two are recently obsoleted, and one has been reworked but not made public yet. He hopes to push it upstream sometime in the future, but can't say when. * Worked on extending Dave Hansen's initial approach to an ashmem alternative. Need to spend some time to find example ashmem code that I can use as a test case to convert to Dave's approach. === Plans === * Continue discussions with Rafael on his wakelock alternative. * Continue on my sched-class based timer-freezing work * Another week, another linaro-android kernel release! * Document my linaro-android kernel process for Deepak. === Issues === * The android.git.linaro.org server seems to be having some serious load issues. Git pushing to it isn't working right now, and its taking forever to respond to web requests.

13 years, 7 months

1
0
0 0

[ACTIVITY][weekly][linaro] (Dave Martin) 2011-10-10 - 2011-10-14

by Dave Martin

== Dave Martin <dmart> == === Activity Summary === * Some more discussions around testing/quality/documentation and use cases for the linaro deliverables. * Some existential discussions around the meaning of __linux__, which Android toolchains seem not to define, causing issues when building against Linux headers. Possible solutions involve defining __linux__ explicitly from a top-level Makefile, or to introduce a new define specifically to mean that the Linux kernel is being built. The android team are now using a temporary solution based on the latter, but the right fix still needs to be agreed. * Useful meeting with Andy Doan and Matt Waddel about having a Connect blueprint session on making Linaro documentation more useful and accessible. * Pinged for further feedback on AMBA module autoloading patches via LKML. * Moved office again. * Still no significant progress on Versatile Express this week, due to discussions and other work. === Plans === (On holiday next week.) Move Versatile Express DT patches forward Prepare for Linaro Connect Prompt for further feedback on minor Thumb-2 randconfig issues: * v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting for Russell/Arnd to comment * Fixing some Thumb-2 related randconfig errors reported by Arnd: * pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for feedback (probably needs a Marvell expert to comment) * tegra2 uses non-Thumb-2-compatible code: waiting for feedback from Colin Cross. === Work Items === (none this week) === Absences === Mon 2011-10-17 - Fri 2011-10-21

13 years, 7 months

1
0
0 0

linaro-android-3.1 tree updated!

by john stultz

After talking with Andy and Alexander, I've re-merged the linaro-3.1 tree with Andy's android tracking tree (currently on 3.1), and am switching to that as the base for the linaro-android-3.1 tree. Hopefully this will assure that there is little difference as possible between the linaro-android tree and Andy's android tracking tree (at least at this moment - tracking trees don't stay still :). I've tagged it as: linux-linaro-3.1-2011.10-0-android-1 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase Apologies to anyone who might have started basing work on the -ozoom-rebase branch. There really should be minimal difference between the two, and so it should be fairly easy to rebase any completed work onto the new branch. thanks -john

13 years, 7 months

2
1
0 0

The linux-linaro-3.1 branch is open

by Nicolas Pitre

Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS: http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summary git://git.linaro.org/kernel/linux-linaro-3.1.git This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet. I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release. Nicolas

13 years, 7 months

8
17
0 0

linaro-android-3.1 tree is open

by John Stultz

With Nicolas releasing the linux-linaro-3.1 branch, I wanted to also announce that the linaro+android-3.1 branch has also opened. I've tag it as: linux-linaro-3.1-2011.10-0-android-0 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-ozoom-rebase Since android.git.kernel.org is still down, and there is no official kernel/common-3.1 branch, I've merged in the forward ported kernel/common-3.0 work done by TI in the omapzoom p-common tree. Thanks to the TI folks for that work! Let me know if there's any trouble. Similarly, I'll be following Nico's linux-linaro-3.0 work in case the 3.1 jump is too aggressive for 11.10. thanks -john

13 years, 7 months

1
0
0 0

Linaro and common- tree

by Andy Green

Hi - Recently at Linaro we've started a new tree linaro-androidization-tracking, which is pretty much "common-3.1"[1] at the moment on 3.1-rc8 basis. http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary We have already been running a kernel tree tracking Linus HEAD since 2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have some experience with the rough and tumble. What we missed having was an "all year round" Androidization tree that we could combine it with to casually create Android versions of the work we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that for a while late in the kernel release cycle when it was tracking Linus HEAD itself and that was great. But common-3.0 like the name suggests is really a release tree, and it stops tracking at release, and a new one starts up only late in the next kernel release cycle. Actually, it would be a big advantage for many folks to not be doing their Android kernel development on lagging releases, but by tracking Linus HEAD. They would have access to latest stuff already and they don't have to think about backport or later forwardport stuff to a new release, it's constantly tracking HEAD and being adapted. One side-effect of using this tracking methodology is if they want release trees, they can just clone their tracking branch at the time Linus HEAD is at a release point and bam, a hopefully fully working release tree is there. Another very nice side-effect is they can do the bulk of the work once on a Vanilla Linus HEAD basis, and get and Android version of that work routinely by merging or rebasing in the Androidization tree - instead of doing and validating work twice on separate Vanilla and Android trees. So linaro-androidization-tracking is our attempt at that Linus HEAD Androidization tree, moving it on regularly and fixing breakage as it happens throughout the cycle. It's generic same as common-, it should be usable for any arch or board to Androidize a vanilla kernel that is on the same Linus HEAD basis just by merge or rebase action. It seemed this effort might be interesting for the guys that make the common- trees, since if there was a tracking Androidization tree, in fact common- releases for release trees like common-3.1 would just naturally fall out of it when Linus HEAD was at 3.1. So I'd be very happy to hear any opinions about that. Another side-issue is we are also looking at refactoring the Androidization patchset into topic branches, at the moment they're kind of reflecting the history that they were applied on plus or minus some munging around. So, all the net core patches for example would be together in one series, then all the wireless ones in a series on top of that, etc. It seems they would be easier to maintain then, opinions on that approach are also welcome. -Andy [1] TI have a tree on omapzoom where we got the patches from http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi… -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 8 months

4
6
0 0

[ACTIVITY] (Thomas Abraham) 2011-10-03 - 2011-09-07

by Thomas Abraham

== Thomas Abraham <thomas-ab> == === Highlights === * Submitted second version of UART and IRQ device tree support patches. * Prepared a single device tree enabled board file for smdkv310 and Origen boards and tested device tree support on both the boards for the following modules: UART, SDHCI, Keypad, GPIO keys, DMA, RTC, I2C, WDT, GPIO, IRQ === Plans === * Submit updated/rebased device tree support patches for SDHCI, Keypad, DMA, RTC, GPIO, IRQ and dt-board file. (hoping that all of these will be merged in 3.2) === Issues === * (Not critical) Testing for backward compatibility with the changes in the drivers for all previous Samsung boards consumes lot of time.

13 years, 8 months

1
0
0 0

[Activity] (Linus Walleij) 2011-10-04 - 2011-10-10

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Maturing pinctrl core and pinmux in linux-next, answering late review comments and merging smaller patches. * Arnd pulled the last ux500 stuff (timers) for the merge window. * Found the problem with attached device trees on my platforms. Root cause: mismatched "compatible" node hangs kernel 3.1+ at an early stage, with an error message on the earlyprintk console. If you don't have a working earlyprintk the stuff locks up, and this non-visibility of early errors had us stuck for a while. * Reviewed various stuff. (pinctrl, MMC, new platform called SPMP8000). === Plans === * Let pin control core and pinmux mature in -next and I expect to issue a pull request to Torvalds in the coming merge window * Start working on generic pin control: - Biasing - Driving - Input modes - Load capacitance First step - survey of existing configuration options for currens SoC:s. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Drive generalization of U300 and Nomadik GPIO by using the pinctrl framework * Watch the DBx500 PRCMU drivers update, fixed patches for Sam, but don't know if he's pleased with them yet. * Mainline some ux500 U-Boot stuff so it can atleast boot the system. === Issues === * The formation of the clk subsystem seems pretty much tangled up in details right now, don't know what to do about it though :-( Thanks, Linus Walleij

13 years, 8 months

1
0
0 0

Announce: TILT tracking Androidization trees

by Andy Green

Hi - TI Landing Team has added a couple of new trees to our git repo over the weekend http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary Both of them track Linus HEAD, currently at 3.1-rc8. First is "linaro-androidization-tracking", this is Linus HEAD plus a set of Androidization patches formed from common-3.0 and common-3.1. "common-3.1 you say?", yes, TI needed a tracking Androidization tree and have made their own public one using pieces from common-3.1. You can find TI's tree that was an ingredient in this here if you're interested, it's public http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi… Due to android.git.kernel.org down, AFAIK there's no public access to common-3.1 direct otherwise at the moment. So what's this tree good for? If you have a kernel for any arch or board that is based on Linus HEAD, 3.1-rc8 at the moment, you can merge or rebase a copy of it with linaro-androidization-tracking to create an Android version of the same kernel. That's very handy if you did your work to get stuff looking good on Vanilla Linus HEAD and don't want to repeat the effort to get the same features coming in an Android kernel. Until now there was no way to casually Androidize a Linus HEAD basis tree unless it happened common-3.x was tracking it, which it only does for a short period at the end. It meant that you had to use old release to start integrating and adding drivers for Android and backport from HEAD anything nice that was coming. Now with this tree, you can do your work on Linus HEAD and fork off working release trees when Linus HEAD goes through a release. This Androidization tree is generic and should be usable for any arch or board, there's nothing TI specific in there. Why then is TI Landing team announcing it / TI go to the effort of creating their original one we based off? Nobody else in Linaro wanted to do the work to create and maintain it, so we own it at the moment. We'll have to see how tough it is to keep tracking Linus HEAD through the post-release patchstorm but reviewing the Androidization patchset I'm cautiously optimistic. I don't have any connection to Google guys who are basically doing the same work on common-3.x, but it would be very cool to be able to cooperate with them on bringing this Androidization patchset forward for everyone's benefit. The second branch is "tilt-android-tracking". This is our main tracking branch tilt-tracking for Panda enablement we have been running for some months combined with "linaro-androidization-tracking" above. This gets you an effective Panda enabled "3.1 preview" kernel that we have had for a while on Vanilla also on Android in an ongoing way. Current status of it is + 1080p SGX acceleration - Suspend borked - WLAN borked But we only generated it Sunday, we are working on those issues now. Lastly TILT is also providing tracking versions of the Android autobuilt Panda-LEB tarballs that are ready to use. These are the Autobuilt tarballs with the kernel replaced with a tracking one by us. You can find them linked from our git repo in tilt-android-tracking column of the status table there. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 8 months

4
7
0 0

[ACTIVITY] (John Stultz) Oct 3rd - 7th

by john stultz

=== Highlights === * Worked on prototyping sched-flag based timer freezing. Initial rough hack allowed a system to drop from 20-60 wakeups per second down to 0.7. The hack is not really viable, so I'm continuing to research and refine the idea to see how it could best be implemented. * Pinged AmitK for ideas on how to measure power improvements. * Resubmit merge_config.sh script to lkml. So far have had no feedback. * Reviewed a rough initial patch by Dave Hansen that could be the start of some ashmem-like functionality. Talked with him about some of the API issues over lunch. * Split up some blueprints for Mounir * Met with PaulMck for lunch to sync up on current issues around my wakelocks idea. * Linaro Connect expenses went through! Yay! === Issues === * N/A

13 years, 8 months

1
0
0 0

[ACTIVITY][weekly][linaro] (Dave Martin) 2011-10-03 - 2011-10-07

by Dave Martin

== Dave Martin <dmart> == === Activity Summary === * More discussions around testing/quality/documentation * Reworked AMBA module autoloading series to Do Things Properly using the existing modpost framework. Posted patches; about 50% Acked. * Thumb-2 kernel migration advice posted on wiki and linaro-dev. * No significant progress on Versatile Express this week, due to discussions and other work. === Plans === Prompt for further feedback on minor Thumb-2 randconfig issues: * v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting for Russell/Arnd to comment * Fixing some Thumb-2 related randconfig errors reported by Arnd: * pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for feedback (probably needs a Marvell expert to comment) * tegra2 uses non-Thumb-2-compatible code: waiting for feedback from Colin Cross. === Work Items === Refined the workitems list for vexpress: kernel-versatile-boad-description-and-implementation: * [dave-martin-arm] Dynamic loading of AMBA device drivers (including via DT) - implement and test: DONE * [dave-martin-arm] Dynamic loading of AMBA device drivers (including via DT) - repost: DONE * [dave-martin-arm] Dynamic loading of AMBA device drivers (including via DT) - Propose for merging: TODO linaro-kernel-o-finish-thump2-support: * [dave-martin-arm] to document what he needed to do get Thumb-2 kernel working for a new SoC: DONE === Absences === Mon 2011-10-17 - Fri 2011-10-21

13 years, 8 months

1
0
0 0

Thumb-2 kernel guide now on the wiki

by Dave Martin

Hi all, For kernel guys and landing teams, I've posted some kernel-specific info on mirating to Thumb-2 here: https://wiki.linaro.org/WorkingGroups/Kernel/Thumb2Guide If your kernel tree isn't building in Thumb-2 yet, please do take a look. Let me know if you want more information on anything, or if you find something that's incorrect or confusing. Cheers ---Dave

13 years, 8 months

1
0
0 0

Linaro and common- tree

by Andy Green

Hi - Recently at Linaro we've started a new tree linaro-androidization-tracking, which is pretty much "common-3.1"[1] at the moment on 3.1-rc8 basis. http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary We have already been running a kernel tree tracking Linus HEAD since 2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have some experience with the rough and tumble. What we missed having was an "all year round" Androidization tree that we could combine it with to casually create Android versions of the work we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that for a while late in the kernel release cycle when it was tracking Linus HEAD itself and that was great. But common-3.0 like the name suggests is really a release tree, and it stops tracking at release, and a new one starts up only late in the next kernel release cycle. Actually, it would be a big advantage for many folks to not be doing their Android kernel development on lagging releases, but by tracking Linus HEAD. They would have access to latest stuff already and they don't have to think about backport or later forwardport stuff to a new release, it's constantly tracking HEAD and being adapted. One side-effect of using this tracking methodology is if they want release trees, they can just clone their tracking branch at the time Linus HEAD is at a release point and bam, a hopefully fully working release tree is there. Another very nice side-effect is they can do the bulk of the work once on a Vanilla Linus HEAD basis, and get and Android version of that work routinely by merging or rebasing in the Androidization tree - instead of doing and validating work twice on separate Vanilla and Android trees. So linaro-androidization-tracking is our attempt at that Linus HEAD Androidization tree, moving it on regularly and fixing breakage as it happens throughout the cycle. It's generic same as common-, it should be usable for any arch or board to Androidize a vanilla kernel that is on the same Linus HEAD basis just by merge or rebase action. It seemed this effort might be interesting for the guys that make the common- trees, since if there was a tracking Androidization tree, in fact common- releases for release trees like common-3.1 would just naturally fall out of it when Linus HEAD was at 3.1. So I'd be very happy to hear any opinions about that. Another side-issue is we are also looking at refactoring the Androidization patchset into topic branches, at the moment they're kind of reflecting the history that they were applied on plus or minus some munging around. So, all the net core patches for example would be together in one series, then all the wireless ones in a series on top of that, etc. It seems they would be easier to maintain then, opinions on that approach are also welcome. -Andy [1] TI have a tree on omapzoom where we got the patches from http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi… (Apologies for any duplication, googlegroups needs mail sent from Google mail) -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 8 months

1
0
0 0

Heads up on kernel.org outage

by Grant Likely

Hi all, I want to give everyone a heads up about the kernel.org outage. As most of you know, kernel.org was compromised by an outside hacker and has been taken down for rebuild. You can find the coverage on lwn.net[1][2][3]. [1] http://lwn.net/Articles/457142/ - Initial notice [2] http://lwn.net/Articles/458809/ - Further details [3] http://lwn.net/Articles/460376/ - An update from H. Peter Alvin Because kernel.org is central to the kernel development process, particularly since the majority of git trees pulled by Linus live there, the security of kernel.org is of paramount importance. It is critically important that when the kernel.org infrastructure comes back up that it not be vulnerable to another attack, so as part of rebuilding the infrastructure, all of the policies around how developers access kernel.org as well as how Linus pulls maintainer trees is under review. The reason for this email is to give you a heads up about what you should expect when kernel.org becomes live again. There is a strong likelyhood that maintainers will need to start GPG signing branches that they will ask Linus to pull. Nothing has been decided firmly (indeed, we won't know until Linus himself makes a decision about what he will accept), and it will definitely be a topic for the upcoming Kernel Summit at the end of October. However, it is worth taking the opportunity now to get familiar with GPG and to create a key for yourself. The Debian developers among you will already be familiar with this process, /even if you don't have a kernel.org account/. The Debian keysigning page[4] is a good place to start reading. [4] http://wiki.debian.org/Keysigning I'll post more details as I learn them. In the mean time, you can email me if you have any questions and I'll do my best to answer them. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

13 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel