linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH 02/07] HWMON: DA9052/53 hwmon driver v1

by Ashish Jangam

The DA9052 PMIC provides an Analogue to Digital Converter with 10 bits resolution and 10 channels. This patch montiors the DA9052 PMIC's ADC channels mostly for battery parameters like battery temperature, junction temperature, battery current etc. This patch is functionally tested on Samsung SMDKV6410. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- Documentation/hwmon/da9052 | 59 +++++++ drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/da9052-hwmon.c | 343 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 413 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/da9052 create mode 100644 drivers/hwmon/da9052-hwmon.c diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052 new file mode 100644 index 0000000..3035bae --- /dev/null +++ b/Documentation/hwmon/da9052 @@ -0,0 +1,59 @@ +Supported chips: + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs + Prefix: 'da9052' + Datasheet: Kindly visit www.dialog-semiconductor.com and request for the + official datasheet. + +Authors: David Dajun Chen <dchen(a)diasemi.com> + +Description +----------- + +The DA9052/53 provides an Analogue to Digital Converter (ADC) with 10 bits +resolution and track and hold circuitry combined with an analogue input +multiplexer. The analogue input multiplexer will allow conversion of up to 10 +different inputs. The track and hold circuit ensures stable input voltages at +the input of the ADC during the conversion. + +The ADC is used to measure the following inputs: +Channel 0: VDDOUT - measurement of the system voltage +Channel 1: ICH - internal battery charger current measurement +Channel 2: TBAT - output from the battery NTC +Channel 3: VBAT - measurement of the battery voltage +Channel 4: ADC_IN4 - high impedance input (0 - 2.5V) +Channel 5: ADC_IN5 - high impedance input (0 - 2.5V) +Channel 6: ADC_IN6 - high impedance input (0 - 2.5V) +Channel 7: XY - TSI interface to measure the X and Y voltage of the touch +screen resistive potentiometers +Channel 8: Internal Tjunc. - sense (internal temp. sensor) +Channel 9: VBBAT - measurement of the backup battery voltage + +By using sysfs attributes we can measure the system voltage VDDOUT, the battery +charging current ICH, battery temperature TBAT, battery junction temperature +TJUNC, battery voltage VBAT and the back up battery voltage VBBAT. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 10 bit ADC. + +The battery voltage is calculated as: + Milli volt = ((ADC value * 1000) / 512) + 2500 + +The voltages on ADC channels 4, 5 and 6 are calculated as: + Milli volt = (ADC value * 2500) / 1023 + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 10 bit ADC. Junction and battery temperatures +are monitored by the ADC channels. + +The junction temperature is calculated: + Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 +The junction temperature attribute is supported by the driver. + +The battery temperature is calculated: + Degree Celcius = 1 / (t1 + 1/298)- 273 +where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255)) +Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively. diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 24d584a..a35d914 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -313,6 +313,16 @@ config SENSORS_DS1621 This driver can also be built as a module. If so, the module will be called ds1621. +config SENSORS_DA9052_ADC + tristate "Dialog DA9052/DA9053 HWMON" + depends on PMIC_DA9052 + help + Say y here to support the ADC found on Dialog Semiconductor + DA9052-BC and DA9053-AA/Bx PMICs. + + This driver can also be built as module. If so, the module + will be called da9052-hwmon. + config SENSORS_EXYNOS4_TMU tristate "Temperature sensor on Samsung EXYNOS4" depends on ARCH_EXYNOS4 diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 8251ce8..5fe96e5 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -42,6 +42,7 @@ obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o +obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o obj-$(CONFIG_SENSORS_DME1737) += dme1737.o obj-$(CONFIG_SENSORS_DS620) += ds620.o obj-$(CONFIG_SENSORS_DS1621) += ds1621.o diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c new file mode 100644 index 0000000..d83f988 --- /dev/null +++ b/drivers/hwmon/da9052-hwmon.c @@ -0,0 +1,343 @@ +/* + * HWMON Driver for Dialog DA9052 + * + * Copyright(c) 2012 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen <dchen(a)diasemi.com> + * + * 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/delay.h> +#include <linux/err.h> +#include <linux/hwmon.h> +#include <linux/hwmon-sysfs.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/platform_device.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> + +struct da9052_hwmon { + struct da9052 *da9052; + struct device *class_device; + struct mutex hwmon_lock; +}; + +static const char * const input_names[] = { + [DA9052_ADC_VDDOUT] = "VDDOUT", + [DA9052_ADC_ICH] = "CHARGING CURRENT", + [DA9052_ADC_TBAT] = "BATTERY TEMP", + [DA9052_ADC_VBAT] = "BATTERY VOLTAGE", + [DA9052_ADC_IN4] = "ADC IN4", + [DA9052_ADC_IN5] = "ADC IN5", + [DA9052_ADC_IN6] = "ADC IN6", + [DA9052_ADC_TJUNC] = "BATTERY JUNCTION TEMP", + [DA9052_ADC_VBBAT] = "BACK-UP BATTERY VOLTAGE", +}; + +static inline int volt_reg_to_mV(int value) +{ + return ((value * 1000) / 512) + 2500; +} + +static inline int input_volt_to_mV(int value) +{ + return (value * 2500) / 1023; +} + +static int da9052_enable_vddout_channel(struct da9052 *da9052) +{ + int ret; + + ret = da9052_reg_read(da9052, DA9052_ADC_CONT_REG); + if (ret < 0) + return ret; + + ret |= DA9052_ADCCONT_AUTOVDDEN; + + return da9052_reg_write(da9052, DA9052_ADC_CONT_REG, ret); +} + +static int da9052_disable_vddout_channel(struct da9052 *da9052) +{ + int ret; + + ret = da9052_reg_read(da9052, DA9052_ADC_CONT_REG); + if (ret < 0) + return ret; + + ret &= ~DA9052_ADCCONT_AUTOVDDEN; + + return da9052_reg_write(da9052, DA9052_ADC_CONT_REG, ret); +} + +static ssize_t da9052_read_vddout(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret, vdd; + + mutex_lock(&hwmon->hwmon_lock); + + ret = da9052_enable_vddout_channel(hwmon->da9052); + if (ret < 0) + goto hwmon_err; + + vdd = da9052_reg_read(hwmon->da9052, DA9052_VDD_RES_REG); + if (vdd < 0) { + ret = vdd; + goto hwmon_err_release; + } + + ret = da9052_disable_vddout_channel(hwmon->da9052); + if (ret < 0) + goto hwmon_err; + + mutex_unlock(&hwmon->hwmon_lock); + vdd = volt_reg_to_mV(vdd); + return sprintf(buf, "%d\n", vdd); + +hwmon_err_release: + da9052_disable_vddout_channel(hwmon->da9052); +hwmon_err: + mutex_unlock(&hwmon->hwmon_lock); + return ret; +} + +static ssize_t da9052_read_ich(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_reg_read(hwmon->da9052, DA9052_ICHG_AV_REG); + if (ret < 0) + return ret; + + /* Equivalent to 3.9mA/bit in register ICHG_AV */ + return sprintf(buf, "%d\n", DIV_ROUND_CLOSEST(ret * 39, 10)); +} + +static ssize_t da9052_read_tbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + + return sprintf(buf, "%d\n", da9052_adc_read_temp(hwmon->da9052)); +} + +static ssize_t da9052_read_vbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, DA9052_ADC_VBAT); + if (ret < 0) + return ret; + + ret = volt_reg_to_mV(ret); + return sprintf(buf, "%d\n", ret); +} + +static ssize_t da9052_read_misc_channel(struct device *dev, + struct device_attribute *devattr, + char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int channel = to_sensor_dev_attr(devattr)->index; + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, channel); + if (ret < 0) + return ret; + if (ret) + ret = input_volt_to_mV(ret); + + return sprintf(buf, "%d\n", ret); +} + +static ssize_t da9052_read_tjunc(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int tjunc, toffset, result; + + tjunc = da9052_reg_read(hwmon->da9052, DA9052_TJUNC_RES_REG); + if (tjunc < 0) + return tjunc; + + toffset = da9052_reg_read(hwmon->da9052, DA9052_T_OFFSET_REG); + if (toffset < 0) + return toffset; + + if ((tjunc - toffset) == 0) + result = 0; + else + /* Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 */ + result = 1708 * (tjunc - toffset) - 108800; + + return sprintf(buf, "%d\n", result); +} + +static ssize_t da9052_read_vbbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, DA9052_ADC_VBBAT); + if (ret < 0) + return ret; + + return sprintf(buf, "%d\n", ret); +} + +static ssize_t da9052_hwmon_show_name(struct device *dev, + struct device_attribute *devattr, + char *buf) +{ + return sprintf(buf, "da9052-hwmon\n"); +} + +static ssize_t show_label(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + return sprintf(buf, "%s\n", + input_names[to_sensor_dev_attr(devattr)->index]); +} + +static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, da9052_read_vddout, NULL, + DA9052_ADC_VDDOUT); +static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VDDOUT); +static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, da9052_read_vbat, NULL, + DA9052_ADC_VBAT); +static SENSOR_DEVICE_ATTR(in3_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VBAT); +static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN4); +static SENSOR_DEVICE_ATTR(in4_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN4); +static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN5); +static SENSOR_DEVICE_ATTR(in5_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN5); +static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN6); +static SENSOR_DEVICE_ATTR(in6_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN6); +static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, da9052_read_vbbat, NULL, + DA9052_ADC_VBBAT); +static SENSOR_DEVICE_ATTR(in9_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VBBAT); + +static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, da9052_read_ich, NULL, + DA9052_ADC_ICH); +static SENSOR_DEVICE_ATTR(curr1_label, S_IRUGO, show_label, NULL, + DA9052_ADC_ICH); + +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, da9052_read_tbat, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, da9052_read_tjunc, NULL, + DA9052_ADC_TJUNC); +static SENSOR_DEVICE_ATTR(temp2_label, S_IRUGO, show_label, NULL, + DA9052_ADC_TJUNC); + +static DEVICE_ATTR(name, S_IRUGO, da9052_hwmon_show_name, NULL); + +static struct attribute *da9052_attr[] = { + &dev_attr_name.attr, + &sensor_dev_attr_in0_input.dev_attr.attr, + &sensor_dev_attr_in0_label.dev_attr.attr, + &sensor_dev_attr_in3_input.dev_attr.attr, + &sensor_dev_attr_in3_label.dev_attr.attr, + &sensor_dev_attr_in4_input.dev_attr.attr, + &sensor_dev_attr_in4_label.dev_attr.attr, + &sensor_dev_attr_in5_input.dev_attr.attr, + &sensor_dev_attr_in5_label.dev_attr.attr, + &sensor_dev_attr_in6_input.dev_attr.attr, + &sensor_dev_attr_in6_label.dev_attr.attr, + &sensor_dev_attr_in9_input.dev_attr.attr, + &sensor_dev_attr_in9_label.dev_attr.attr, + &sensor_dev_attr_curr1_input.dev_attr.attr, + &sensor_dev_attr_curr1_label.dev_attr.attr, + &sensor_dev_attr_temp1_input.dev_attr.attr, + &sensor_dev_attr_temp1_label.dev_attr.attr, + &sensor_dev_attr_temp2_input.dev_attr.attr, + &sensor_dev_attr_temp2_label.dev_attr.attr, + NULL +}; + +static const struct attribute_group da9052_attr_group = {.attrs = da9052_attr}; + +static int __init da9052_hwmon_probe(struct platform_device *pdev) +{ + struct da9052_hwmon *hwmon; + int ret; + + hwmon = devm_kzalloc(&pdev->dev, sizeof(struct da9052_hwmon), + GFP_KERNEL); + if (!hwmon) + return -ENOMEM; + + mutex_init(&hwmon->hwmon_lock); + hwmon->da9052 = dev_get_drvdata(pdev->dev.parent); + + platform_set_drvdata(pdev, hwmon); + + ret = sysfs_create_group(&pdev->dev.kobj, &da9052_attr_group); + if (ret) + goto err_mem; + + hwmon->class_device = hwmon_device_register(&pdev->dev); + if (IS_ERR(hwmon->class_device)) { + ret = PTR_ERR(hwmon->class_device); + goto err_sysfs; + } + + return 0; + +err_sysfs: + sysfs_remove_group(&pdev->dev.kobj, &da9052_attr_group); +err_mem: + devm_kfree(&pdev->dev, hwmon); + return ret; +} + +static int __devexit da9052_hwmon_remove(struct platform_device *pdev) +{ + struct da9052_hwmon *hwmon = platform_get_drvdata(pdev); + + hwmon_device_unregister(hwmon->class_device); + sysfs_remove_group(&pdev->dev.kobj, &da9052_attr_group); + devm_kfree(&pdev->dev, hwmon); + + return 0; +} + +static struct platform_driver da9052_hwmon_driver = { + .probe = da9052_hwmon_probe, + .remove = __devexit_p(da9052_hwmon_remove), + .driver = { + .name = "da9052-hwmon", + .owner = THIS_MODULE, + }, +}; + +module_platform_driver(da9052_hwmon_driver); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("DA9052 HWMON driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-hwmon");

13 years, 3 months

Multimedia Work Group at Linaro Connect

by Tom Gall

http://connect.linaro.org/events/event/lcq1-12/#schedule The Linaro Multimedia Team for 1Q Linaro Connect has 3 main goals. 1) We'll be identifying further candidates for NEON focused optimization.2) We'll be syncing up with the landing teams to discuss the state of audio on the various boards, thinking about how we can be more effective, and planning our next efforts.3) We'll be working with the Graphics team on the next steps surrounding dmb_buf usage. In summary the sessions are: Codecs:Codec NEON optimization - possibilities and priorities Audio:Tiny AlsaLinaro speech recognitionPanda, Panda ES audio Snowball AudioOrigen Audioimx53 audio Unified Memory Manager:Evolution of the general dma-buf frameworkUMM - further enablement on member platforms I would anticipate we'll add a neon session so be on the lookout for that! Stop by and interact with the team, we're located in Salon 3 on the 2nd floor with the Graphics team. -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 3 months

How to participate in the connect remotely

by Zygmunt Krynicki

Hi. I'm curious how/if remote participation is going to work during this connect. Unlike past events we will not have the advantage of the Canonical IS teams that made everything just work. This probably includes the microphones in each room, the IRC channels, the projectors and the magic wifi. Is there any general way to participate remotely during this event or should I just bug my friends to place a laptop on a chair and run google hangouts? Thanks ZK -- Zygmunt Krynicki Linaro Validation Team

13 years, 3 months

Developer Platform, Plans and Goals for Connect

by Ricardo Salveti

Hey, Additionally to the sessions we'll have over the week, here are another 2 important links for our group: - Plans and Goals for Linaro Connect Q1.12: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/Plans - Hacking Sessions: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/HackingSessions If you're interested on having a 'hands-on' at any topic described at this wiki pages, please visit room Salon 4. We have all needed hardware there, from boards to monitors, so we can easily get on hacking. Thanks, -- Ricardo Salveti de Araujo

13 years, 3 months

[PATCH v8 0/4] Add SMDK5250 board support

by Chander Kashyap

This patchset add support for Samsung's SMDK5250 board based on EXYNOS5250 based SoC. It also adds support for MMC SPL booting. The porting is done by Samsung engineers at HQ in System LSI Team. I am contributing in upstreaming the code for the board. Based upon discussions following patches are dropped in this version: Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards Exynos: Clock.c: Replace exynos4 prefix with exynos SMDK5250: enable device tree support is squashed with EXYNOS: Add SMDK5250 board support Chander Kashyap (4): Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro ARM: EXYNOS: Add support for Exynos5 based SoCs EXYNOS: Add SMDK5250 board support EXYNOS: SMDK5250: Add MMC SPL support MAINTAINERS | 1 + arch/arm/cpu/armv7/exynos/clock.c | 214 +++++++++++++- arch/arm/include/asm/arch-exynos/clock.h | 326 +++++++++++++++++++++ arch/arm/include/asm/arch-exynos/cpu.h | 35 +++- arch/arm/include/asm/arch-exynos/dmc.h | 146 ++++++++++ arch/arm/include/asm/arch-exynos/gpio.h | 99 ++++++- arch/arm/include/asm/arch-exynos/tzpc.h | 52 ++++ board/samsung/smdk5250/Makefile | 58 ++++ board/samsung/smdk5250/clock_init.c | 202 +++++++++++++ board/samsung/smdk5250/dmc_init.c | 462 ++++++++++++++++++++++++++++++ board/samsung/smdk5250/lowlevel_init.S | 96 ++++++ board/samsung/smdk5250/mmc_boot.c | 58 ++++ board/samsung/smdk5250/setup.h | 451 +++++++++++++++++++++++++++++ board/samsung/smdk5250/smdk5250.c | 146 ++++++++++ board/samsung/smdk5250/tzpc_init.c | 48 +++ boards.cfg | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/smdk5250.h | 197 +++++++++++++ include/configs/trats.h | 1 + tools/Makefile | 6 + tools/mksmdk5250spl.c | 119 ++++++++ 21 files changed, 2702 insertions(+), 17 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/dmc.h create mode 100644 arch/arm/include/asm/arch-exynos/tzpc.h create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/clock_init.c create mode 100644 board/samsung/smdk5250/dmc_init.c create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mmc_boot.c create mode 100644 board/samsung/smdk5250/setup.h create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/tzpc_init.c create mode 100644 include/configs/smdk5250.h create mode 100644 tools/mksmdk5250spl.c -- 1.7.5.4

13 years, 3 months

Connect sessions from the Android Platform Team

by Tony Mansson

13 years, 3 months

Validation at the Linaro Connect

by Paul Larson

Interested in Validation and going to the Linaro connect? Here are some of the sessions already scheduled that you might be interested in on the Validation track: Automated bootloader testing in LAVA https://blueprints.launchpad.net/lava-dispatcher/+spec/linaro-validation-q1… Discuss what needs to be done still on celery, and usage https://blueprints.launchpad.net/lava-lab/+spec/linaro-validation-q112-lava… LAVA Server Admin tools https://blueprints.launchpad.net/lava-server/+spec/linaro-validation-q112-a… Discuss test plans for big.LITTLE https://blueprints.launchpad.net/lava-test/+spec/linaro-validation-q112-big… Monitoring and managing device health in LAVA https://blueprints.launchpad.net/lava-lab/+spec/linaro-validation-q112-devi… Additionally, here are some sessions in other tracks that you may like: Ubuntu LEB and LAVA: Current status and future planning for proper image testing and validation https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-… Linaro's Kernel CI Process discussion and Feedback https://blueprints.launchpad.net/linaro/+spec/linaro-kernel-ci-q112-discuss… End to End Demo of Enabling Something for LAVA https://blueprints.launchpad.net/linaro/+spec/linaro-training-q112-end-to-e… Make sure to check http://summit.linaro.org/lcq1-12/track/linaro-validation/throughout the week for changes and additions. If you are around in the afternoons and want to help out on LAVA development, or want help getting started in it, swing by the validation hacking sessions and talk to us. See you next week!

13 years, 3 months

native gdb for Android

by Barry Song

Hi guys, I compile a native gdb using linaro 2011.10 by “./configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and the gdb runs on arm target boards directly. # gdb GNU gdb (Linaro GDB) 7.3-2011.10 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-none-linux-gnueabi". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. (gdb) I can use it to debug native programs on target boards directly. For example, attach process, set breakpoints, check registers and memory. One issue is I can't see multi-threads, for example: PID 646 is system_server by ps "646 1000 159m S system_server" Then I use gdb to attach it: # gdb attach 646 (gdb) info threads Id Target Id Frame * 1 process 646 "system_server" __ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15 as you see, “info threads” only shows one thread but there are several threads in system_server. But if I compile a new program based on glibc and gnu libthread, I can see multi-threads by the gdb. So my questions are: 1. Should I compile the native gdb using android toolchain and android bionic/libthread libraries? 2. Why can’t the current gdb capture multithreads for android processes? This question is actually about the theory for gdb to know multi-threads. In my opinion, both gnu and android use clone() to fork threads and threads in one process have same tgid in kernel and all threads return same getpid() value. Why not gdb just travel process lists to find multi-threads? Thanks Barry

13 years, 3 months

[PATCH V6 0/7] add a generic cpufreq driver

by Richard Zhao

The driver is based on clock and regulator APIs and support single core and multi core ARM SoCs. For multi core, it assume all cores share the same clock and voltage. Thanks Arnd, Mark, Jamie, Shawn, Rob, for your review. Changes in V6: - add scaling_available_freqs Changes in V5: - add more comments - rename trans-latency to clk-trans-latency, and it only describe clk latency. Regulator latency is got from regulator_set_voltage_time. Changes in v4: - add depends on HAVE_CLK && OF && REGULATOR - add set_cpu_freq fail check - regulator_put wehn module exit - add pr_fmt and convert all printk to pr_xxx - use voltage range - comment and doc fix - add cpu_volts value pre-check in module init - add helpfull module parameter max_freq - remove compatible string check on Arnd's comment. - remove generic-cpufreq to clk-reg-cpufreq Changes in v3: - move adjusting smp loops_per_jiffy to arm common code, and also adjust global loops_per_jiffy. - remove adjusting loops_per_jiffy in imx and omap cpufreq drivers. - check compatible "generic-cpufreq" when module_init - change printk to pr_xxx - add generic-cpufreq DT binding doc Changes in v2: - add volatage change support - change '_' in property name to '-' - use initial value to calculate loops_per_jiffy - fix reading cpu_volts property bug - let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min - don't change freq in arm_cpufreq_exit, because every core share the same freq. - use unsigned long describe frequency as much as possible. Because clk use unsigned long, but cpufreq use unsigned int. [PATCH V6 1/7] ARM: add cpufreq transiton notifier to adjust [PATCH V6 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate [PATCH V6 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for [PATCH V6 4/7] cpufreq: add clk-reg cpufreq driver [PATCH V6 5/7] dts/imx6q: add cpufreq property [PATCH V6 6/7] arm/imx6q: register arm_clk as cpu to clkdev [PATCH V6 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ Thanks Richard

13 years, 3 months

[Activity] Toolchain WG Weekly Status report for week ending 2012-02-03

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report & meeting minutes for the Toolchain working group for the week ending 2012-02-03 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2012-02-02 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-02-02 == Weekly Activity report == https://wiki.linaro.org/WorkingGroups/ToolChain/ActivityReports/2012-01-27 == Summary == (For details, see the Weekly Status Report, Meeting Minutes and Weekly Activity reports) * Roadmap / Connect * Completed End of quarter 2011Q4 reports * Set the sessions for Connect * Plan for 2012Q1 https://wiki.linaro.org/MichaelHope/Sandbox/Q1.12Plans * 64-bit * Submitted work on 64-bit shift in core registers patches upstream, awaiting review. * libunwind * Reviewed a patch from T. R. of Nokia who provided a bugfix in case unwind instructions are popping VFP registers * OpenEmbedded * Changed Qt build to respect the optimization flags * Wrote a script around QEMU to measure the memory footprint using named pipes to communicate with the serial console of the guest * GDB * Committed follow-on patch to fix cosmetic issues resulting from the remote "info proc" patch set. * GCC * Created 4.6 backport branch including subreg forward- propagation branch, the modes-tieable patch, and the combine.c regression fix, and evaluated for correctness and performance. * Investigated Ramana's vld1 patches, and a problem with excessive vmov's in the PR 51819 test case pointed out by Ramana. * QEMU * Wrote patches for the A15 Fast Models boot-wrapper that allow you to pass the kernel/initrd/kernel command line via a parameter to the model rather than having to hard code them into an ELF file along with the boot-wrapper. * target-arm/arm-devs queues pushed upstream [Calxeda Highbank model is now in upstream QEMU] * KVM * Sorted out a Debian fs to use for KVM guest : this is needed because the kernel module doesn't do Thumb or VFP yet. * Wrote wiki pages on how to reproduce the KVM prototype https://wiki.linaro.org/PeterMaydell/KVM/HowTo * Upstream patch review, many complicated things landing * Reviewed KVM ARM patches from Christoffer * Benchmarking * Continued benchmarking gcc-4.7 against gcc-linaro-4.6-2012.01 and gcc-4.6 with -o2 and -o3 variants, both with neon enabled. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev