linaro-dev October 2011

linaro-dev@lists.linaro.org

107 participants
156 discussions

[Patch 5/11] Regulator: DA9052/53 regulator support v5

by ashishj3

The Dialog PMIC has below featured regulators:- DA9052-BC - 4 DVS Buck converters 0.5V - 3.6V upto 1Amp. DA9053-AA/BX - 4 DVS Buck converters 0.5V - 2.5V upto 3Amp. DA9052/53 - 10 Programmable LDO's High PSSR, 1% accuracy. This patch support all the DA9052 and Da9053 regulators. The output voltages are fully programmable via I2C or SPI interface. The platform data with regulation constraints is passed down from the board to the regulator. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org> CC: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Changes since v5 - Modify Kconfig to describe the config symbol - Change file permissions - remove execute permission - Line 43 - Adjust for 80 characters width Changes since v4 - Add support for DA9053 - Correct the definition of macros DA9052_BUCK_ILIM_MASK - Get current limit to return current limit in microA - Correct the voltage selector value for Buck Peri above 3v - Set the struct member regualtor->da9052 in probe() Changes since v3 - Corrected verify_range function Changes since v2 - Check for current min_uA < 700000 - Corrected current conversions from mA to uA --- drivers/regulator/Kconfig | 7 + drivers/regulator/Makefile | 1 + drivers/regulator/da9052-regulator.c | 600 ++++++++++++++++++++++++++++++++++ 3 files changed, 608 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/da9052-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 9713b1b..4f4774b 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -177,6 +177,13 @@ config REGULATOR_DA903X Say y here to support the BUCKs and LDOs regulators found on Dialog Semiconductor DA9030/DA9034 PMIC. +config REGULATOR_DA9052 + tristate "Dialog DA9052/DA9053 regulators" + depends on PMIC_DA9052 + help + This driver supports the voltage regulators of DA9052-BC and + DA9053-AA/Bx PMIC. + config REGULATOR_PCF50633 tristate "PCF50633 regulator driver" depends on MFD_PCF50633 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 93a6318..07b2126 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o obj-$(CONFIG_REGULATOR_DA903X) += da903x.o +obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c new file mode 100644 index 0000000..9b75425 --- /dev/null +++ b/drivers/regulator/da9052-regulator.c @@ -0,0 +1,600 @@ +/* +* da9052-regulator.c: Regulator driver for DA9052 +* +* Copyright(c) 2011 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/module.h> +#include <linux/moduleparam.h> +#include <linux/init.h> +#include <linux/err.h> +#include <linux/platform_device.h> +#include <linux/regulator/driver.h> +#include <linux/regulator/machine.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> +#include <linux/mfd/da9052/pdata.h> + +/* Buck step size */ +#define DA9052_BUCK_PERI_3uV_STEP 100000 +#define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV 24 +#define DA9052_CONST_3uV 3000000 + +#define DA9052_MIN_UA 0 +#define DA9052_MAX_UA 3 +#define DA9052_CURRENT_RANGE 4 + +/* Bit masks */ +#define DA9052_BUCK_ILIM_MASK_EVEN 0x0c +#define DA9052_BUCK_ILIM_MASK_ODD 0xc0 + +static const u32 da9052_current_limits[3][4] = { + {700000, 800000, 1000000, 1200000}, /* DA9052-BC BUCKs */ + {1600000, 2000000, 2400000, 3000000}, /* DA9053-AA/Bx BUCK-CORE */ + {800000, 1000000, 1200000, 1500000}, /* DA9053-AA/Bx BUCK-PRO, + * BUCK-MEM and BUCK-PERI + */ +}; + +struct da9052_regulator_info { + struct regulator_desc reg_desc; + int step_uV; + int min_uV; + int max_uV; + unsigned char volt_shift; + unsigned char en_bit; + unsigned char activate_bit; +}; + +struct da9052_regulator { + struct da9052 *da9052; + struct da9052_regulator_info *info; + struct regulator_dev *rdev; +}; + +static int verify_range(struct da9052_regulator_info *info, + int min_uV, int max_uV) +{ + if (min_uV > info->max_uV || max_uV < info->min_uV) + return -EINVAL; + + return 0; +} + +static int da9052_regulator_enable(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + + return da9052_reg_update(regulator->da9052, + DA9052_BUCKCORE_REG + offset, + 1 << info->en_bit, 1 << info->en_bit); +} + +static int da9052_regulator_disable(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + + return da9052_reg_update(regulator->da9052, + DA9052_BUCKCORE_REG + offset, + 1 << info->en_bit, 0); +} + +static int da9052_regulator_is_enabled(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + int ret; + + ret = da9052_reg_read(regulator->da9052, DA9052_BUCKCORE_REG + offset); + if (ret < 0) + return ret; + + return ret & (1 << info->en_bit); +} + +static int da9052_dcdc_get_current_limit(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + int offset = rdev_get_id(rdev); + int ret, row = 2; + + ret = da9052_reg_read(regulator->da9052, DA9052_BUCKA_REG + offset/2); + if (ret < 0) + return ret; + + /* Determine the even or odd position of the buck current limit + * register field + */ + if (offset % 2 == 0) + ret = (ret & DA9052_BUCK_ILIM_MASK_EVEN) >> 2; + else + ret = (ret & DA9052_BUCK_ILIM_MASK_ODD) >> 6; + + /* Select the appropriate current limit range */ + if (regulator->da9052->chip_id == DA9052) + row = 0; + else if (offset == 0) + row = 1; + + return da9052_current_limits[row][ret]; +} + +static int da9052_dcdc_set_current_limit(struct regulator_dev *rdev, int min_uA, + int max_uA) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + int offset = rdev_get_id(rdev); + int reg_val = 0; + int i, row = 2; + + /* Select the appropriate current limit range */ + if (regulator->da9052->chip_id == DA9052) + row = 0; + else if (offset == 0) + row = 1; + + if (min_uA > da9052_current_limits[row][DA9052_MAX_UA] || + max_uA < da9052_current_limits[row][DA9052_MIN_UA]) + return -EINVAL; + + for (i = 0; i < DA9052_CURRENT_RANGE; i++) { + if (min_uA <= da9052_current_limits[row][i]) { + reg_val = i; + break; + } + } + + /* Determine the even or odd position of the buck current limit + * register field + */ + if (offset % 2 == 0) + return da9052_reg_update(regulator->da9052, + DA9052_BUCKA_REG + offset/2, + DA9052_BUCK_ILIM_MASK_EVEN, + reg_val << 2); + else + return da9052_reg_update(regulator->da9052, + DA9052_BUCKA_REG + offset/2, + DA9052_BUCK_ILIM_MASK_ODD, + reg_val << 6); +} + +static int da9052_list_buckperi_voltage(struct regulator_dev *rdev, + unsigned int selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int volt_uV; + + if ((regulator->da9052->chip_id == DA9052) && + (selector >= DA9052_BUCK_PERI_REG_MAP_UPTO_3uV)) { + volt_uV = ((DA9052_BUCK_PERI_REG_MAP_UPTO_3uV * info->step_uV) + + info->min_uV); + volt_uV += (selector - DA9052_BUCK_PERI_REG_MAP_UPTO_3uV) + * (DA9052_BUCK_PERI_3uV_STEP); + } else + volt_uV = (selector * info->step_uV) + info->min_uV; + + if (volt_uV > info->max_uV) + return -EINVAL; + + return volt_uV; +} + +static int da9052_list_voltage(struct regulator_dev *rdev, + unsigned int selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int volt_uV; + + volt_uV = info->min_uV + info->step_uV * selector; + + if (volt_uV > info->max_uV) + return -EINVAL; + + return volt_uV; +} + +static int da9052_regulator_set_voltage_int(struct regulator_dev *rdev, + int min_uV, int max_uV, + unsigned int *selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + int ret; + + ret = verify_range(info, min_uV, max_uV); + if (ret < 0) + return ret; + + if (min_uV < info->min_uV) + min_uV = info->min_uV; + + *selector = (min_uV - info->min_uV) / info->step_uV; + + ret = da9052_list_voltage(rdev, *selector); + if (ret < 0) + return ret; + + return da9052_reg_update(regulator->da9052, + DA9052_BUCKCORE_REG + offset, + (1 << info->volt_shift) - 1, *selector); +} + +static int da9052_set_ldo_voltage(struct regulator_dev *rdev, + int min_uV, int max_uV, + unsigned int *selector) +{ + return da9052_regulator_set_voltage_int(rdev, min_uV, max_uV, selector); +} + +static int da9052_set_ldo5_6_voltage(struct regulator_dev *rdev, + int min_uV, int max_uV, + unsigned int *selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int ret; + + ret = da9052_regulator_set_voltage_int(rdev, min_uV, max_uV, selector); + if (ret < 0) + return ret; + + /* Some LD0s are DVC controlled which requires enabling of + * the LDO activate bit to implment the changes on the + * LDO output. + */ + return da9052_reg_update(regulator->da9052, DA9052_SUPPLY_REG, 0, + info->activate_bit); +} + +static int da9052_set_dcdc_voltage(struct regulator_dev *rdev, + int min_uV, int max_uV, + unsigned int *selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int ret; + + ret = da9052_regulator_set_voltage_int(rdev, min_uV, max_uV, selector); + if (ret < 0) + return ret; + + /* Some DCDCs are DVC controlled which requires enabling of + * the DCDC activate bit to implment the changes on the + * DCDC output. + */ + return da9052_reg_update(regulator->da9052, DA9052_SUPPLY_REG, 0, + info->activate_bit); +} + +static int da9052_get_regulator_voltage_sel(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + int ret; + + ret = da9052_reg_read(regulator->da9052, DA9052_BUCKCORE_REG + offset); + if (ret < 0) + return ret; + + ret &= ((1 << info->volt_shift) - 1); + + return ret; +} + +static int da9052_set_buckperi_voltage(struct regulator_dev *rdev, int min_uV, + int max_uV, unsigned int *selector) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + int ret; + + ret = verify_range(info, min_uV, max_uV); + if (ret < 0) + return ret; + + if (min_uV < info->min_uV) + min_uV = info->min_uV; + + if ((regulator->da9052->chip_id == DA9052) && + (min_uV >= DA9052_CONST_3uV)) + *selector = DA9052_BUCK_PERI_REG_MAP_UPTO_3uV + + ((min_uV - DA9052_CONST_3uV) / + (DA9052_BUCK_PERI_3uV_STEP)); + else + *selector = (min_uV - info->min_uV) / info->step_uV; + + ret = da9052_list_buckperi_voltage(rdev, *selector); + if (ret < 0) + return ret; + + return da9052_reg_update(regulator->da9052, + DA9052_BUCKCORE_REG + offset, + (1 << info->volt_shift) - 1, *selector); +} + +static int da9052_get_buckperi_voltage_sel(struct regulator_dev *rdev) +{ + struct da9052_regulator *regulator = rdev_get_drvdata(rdev); + struct da9052_regulator_info *info = regulator->info; + int offset = rdev_get_id(rdev); + int ret; + + ret = da9052_reg_read(regulator->da9052, DA9052_BUCKCORE_REG + offset); + if (ret < 0) + return ret; + + ret &= ((1 << info->volt_shift) - 1); + + return ret; +} + +static struct regulator_ops da9052_buckperi_ops = { + .list_voltage = da9052_list_buckperi_voltage, + .get_voltage_sel = da9052_get_buckperi_voltage_sel, + .set_voltage = da9052_set_buckperi_voltage, + + .get_current_limit = da9052_dcdc_get_current_limit, + .set_current_limit = da9052_dcdc_set_current_limit, + + .is_enabled = da9052_regulator_is_enabled, + .enable = da9052_regulator_enable, + .disable = da9052_regulator_disable, +}; + +static struct regulator_ops da9052_dcdc_ops = { + .set_voltage = da9052_set_dcdc_voltage, + .get_current_limit = da9052_dcdc_get_current_limit, + .set_current_limit = da9052_dcdc_set_current_limit, + + .list_voltage = da9052_list_voltage, + .get_voltage_sel = da9052_get_regulator_voltage_sel, + .is_enabled = da9052_regulator_is_enabled, + .enable = da9052_regulator_enable, + .disable = da9052_regulator_disable, +}; + +static struct regulator_ops da9052_ldo5_6_ops = { + .set_voltage = da9052_set_ldo5_6_voltage, + + .list_voltage = da9052_list_voltage, + .get_voltage_sel = da9052_get_regulator_voltage_sel, + .is_enabled = da9052_regulator_is_enabled, + .enable = da9052_regulator_enable, + .disable = da9052_regulator_disable, +}; + +static struct regulator_ops da9052_ldo_ops = { + .set_voltage = da9052_set_ldo_voltage, + + .list_voltage = da9052_list_voltage, + .get_voltage_sel = da9052_get_regulator_voltage_sel, + .is_enabled = da9052_regulator_is_enabled, + .enable = da9052_regulator_enable, + .disable = da9052_regulator_disable, +}; + +#define DA9052_LDO5_6(_id, step, min, max, sbits, ebits, abits) \ +{\ + .reg_desc = {\ + .name = "LDO" #_id,\ + .ops = &da9052_ldo5_6_ops,\ + .type = REGULATOR_VOLTAGE,\ + .id = _id,\ + .owner = THIS_MODULE,\ + },\ + .min_uV = (min) * 1000,\ + .max_uV = (max) * 1000,\ + .step_uV = (step) * 1000,\ + .volt_shift = (sbits),\ + .en_bit = (ebits),\ + .activate_bit = (abits),\ +} + +#define DA9052_LDO(_id, step, min, max, sbits, ebits, abits) \ +{\ + .reg_desc = {\ + .name = "LDO" #_id,\ + .ops = &da9052_ldo_ops,\ + .type = REGULATOR_VOLTAGE,\ + .id = _id,\ + .owner = THIS_MODULE,\ + },\ + .min_uV = (min) * 1000,\ + .max_uV = (max) * 1000,\ + .step_uV = (step) * 1000,\ + .volt_shift = (sbits),\ + .en_bit = (ebits),\ + .activate_bit = (abits),\ +} + +#define DA9052_DCDC(_id, step, min, max, sbits, ebits, abits) \ +{\ + .reg_desc = {\ + .name = "BUCK" #_id,\ + .ops = &da9052_dcdc_ops,\ + .type = REGULATOR_VOLTAGE,\ + .id = _id,\ + .owner = THIS_MODULE,\ + },\ + .min_uV = (min) * 1000,\ + .max_uV = (max) * 1000,\ + .step_uV = (step) * 1000,\ + .volt_shift = (sbits),\ + .en_bit = (ebits),\ + .activate_bit = (abits),\ +} + +#define DA9052_BUCKPERI(_id, step, min, max, sbits, ebits, abits) \ +{\ + .reg_desc = {\ + .name = "BUCK" #_id,\ + .ops = &da9052_buckperi_ops,\ + .type = REGULATOR_VOLTAGE,\ + .id = _id,\ + .owner = THIS_MODULE,\ + },\ + .min_uV = (min) * 1000,\ + .max_uV = (max) * 1000,\ + .step_uV = (step) * 1000,\ + .volt_shift = (sbits),\ + .en_bit = (ebits),\ + .activate_bit = (abits),\ +} + +struct da9052_regulator_info da9052_regulator_info[] = { + /* Buck1 - 4 */ + DA9052_DCDC(0, 25, 500, 2075, 6, 6, DA9052_SUPPLY_VBCOREGO), + DA9052_DCDC(1, 25, 500, 2075, 6, 6, DA9052_SUPPLY_VBPROGO), + DA9052_DCDC(2, 25, 925, 2500, 6, 6, DA9052_SUPPLY_VBMEMGO), + DA9052_BUCKPERI(3, 50, 1800, 3600, 5, 6, 0), + /* LD01 - LDO10 */ + DA9052_LDO(4, 50, 600, 1800, 5, 6, 0), + DA9052_LDO5_6(5, 25, 600, 1800, 6, 6, DA9052_SUPPLY_VLDO2GO), + DA9052_LDO5_6(6, 25, 1725, 3300, 6, 6, DA9052_SUPPLY_VLDO3GO), + DA9052_LDO(7, 25, 1725, 3300, 6, 6, 0), + DA9052_LDO(8, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(9, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(10, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(11, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(12, 50, 1250, 3650, 6, 6, 0), + DA9052_LDO(13, 50, 1200, 3600, 6, 6, 0), +}; + +struct da9052_regulator_info da9053_regulator_info[] = { + /* Buck1 - 4 */ + DA9052_DCDC(0, 25, 500, 2075, 6, 6, DA9052_SUPPLY_VBCOREGO), + DA9052_DCDC(1, 25, 500, 2075, 6, 6, DA9052_SUPPLY_VBPROGO), + DA9052_DCDC(2, 25, 925, 2500, 6, 6, DA9052_SUPPLY_VBMEMGO), + DA9052_BUCKPERI(3, 25, 925, 2500, 6, 6, 0), + /* LD01 - LDO10 */ + DA9052_LDO(4, 50, 600, 1800, 5, 6, 0), + DA9052_LDO5_6(5, 25, 600, 1800, 6, 6, DA9052_SUPPLY_VLDO2GO), + DA9052_LDO5_6(6, 25, 1725, 3300, 6, 6, DA9052_SUPPLY_VLDO3GO), + DA9052_LDO(7, 25, 1725, 3300, 6, 6, 0), + DA9052_LDO(8, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(9, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(10, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(11, 50, 1200, 3600, 6, 6, 0), + DA9052_LDO(12, 50, 1250, 3650, 6, 6, 0), + DA9052_LDO(13, 50, 1200, 3600, 6, 6, 0), +}; + +static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id, + int id) +{ + struct da9052_regulator_info *info; + int i; + + if (chip_id == DA9052) { + for (i = 0; i < ARRAY_SIZE(da9052_regulator_info); i++) { + info = &da9052_regulator_info[i]; + if (info->reg_desc.id == id) + return info; + } + } else { + for (i = 0; i < ARRAY_SIZE(da9053_regulator_info); i++) { + info = &da9053_regulator_info[i]; + if (info->reg_desc.id == id) + return info; + } + } + + return NULL; +} + +static int __devinit da9052_regulator_probe(struct platform_device *pdev) +{ + struct da9052_regulator *regulator; + struct da9052 *da9052; + struct da9052_pdata *pdata; + int ret; + + regulator = kzalloc(sizeof(struct da9052_regulator), GFP_KERNEL); + if (!regulator) + return -ENOMEM; + + da9052 = dev_get_drvdata(pdev->dev.parent); + pdata = da9052->dev->platform_data; + regulator->da9052 = da9052; + + regulator->info = find_regulator_info(regulator->da9052->chip_id, + pdev->id); + if (regulator->info == NULL) { + dev_err(&pdev->dev, "invalid regulator ID specified\n"); + ret = -EINVAL; + goto err; + } + regulator->rdev = regulator_register(&regulator->info->reg_desc, + &pdev->dev, + pdata->regulators[pdev->id], + regulator); + if (IS_ERR(regulator->rdev)) { + dev_err(&pdev->dev, "failed to register regulator %s\n", + regulator->info->reg_desc.name); + ret = PTR_ERR(regulator->rdev); + goto err; + } + + platform_set_drvdata(pdev, regulator); + + return 0; +err: + kfree(regulator); + return ret; +} + +static int __devexit da9052_regulator_remove(struct platform_device *pdev) +{ + struct da9052_regulator *regulator = platform_get_drvdata(pdev); + + regulator_unregister(regulator->rdev); + kfree(regulator); + + return 0; +} + +static struct platform_driver da9052_regulator_driver = { + .probe = da9052_regulator_probe, + .remove = __devexit_p(da9052_regulator_remove), + .driver = { + .name = "da9052-regulator", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_regulator_init(void) +{ + return platform_driver_register(&da9052_regulator_driver); +} +subsys_initcall(da9052_regulator_init); + +static void __exit da9052_regulator_exit(void) +{ + platform_driver_unregister(&da9052_regulator_driver); +} +module_exit(da9052_regulator_exit); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("Power Regulator driver for Dialog DA9052 PMIC"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-regulator");

12 years, 6 months

[Patch 04/11]Power: DA9052 battery driver v4

by Ashish Jangam

Driver for DA9052 battery charger. This driver depends on DA9052 MFD core dirver for definitions and methods. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- Changes since v3 - Included power_supply.h file - Corrected the definition of DA9052_BAT_THRESHOLD macro - Changed definition of charger_type_enum - Added API da9052_battery_read_end_current - Added API da9052_battery_check_status - Changed the way of handling the interrupts in da9052_bat_irq Changes since v2 - Correct code styling for inline functions - Remove averaging algorithm - Set use_for_apm thru board specific parameter --- drivers/power/Kconfig | 7 + drivers/power/Makefile | 1 + drivers/power/da9052-battery.c | 611 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 619 insertions(+), 0 deletions(-) create mode 100755 drivers/power/da9052-battery.c diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 57de051..c041712 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -149,6 +149,13 @@ config BATTERY_DA9030 Say Y here to enable support for batteries charger integrated into DA9030 PMIC. +config BATTERY_DA9052 + tristate "Dialog DA9052 Battery" + depends on PMIC_DA9052 + help + Say Y here to enable support for batteries charger integrated into + DA9052 PMIC. + config BATTERY_MAX17040 tristate "Maxim MAX17040 Fuel Gauge" depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index b4af13d..c570e20 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o obj-$(CONFIG_BATTERY_BQ20Z75) += bq20z75.o obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o +obj-$(CONFIG_BATTERY_DA9052) += da9052-battery.o obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o obj-$(CONFIG_BATTERY_Z2) += z2_battery.o diff --git a/drivers/power/da9052-battery.c b/drivers/power/da9052-battery.c new file mode 100755 index 0000000..d9096df --- /dev/null +++ b/drivers/power/da9052-battery.c @@ -0,0 +1,611 @@ +/* + * Batttery Driver for Dialog DA9052 PMICs + * + * Copyright(c) 2011 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/freezer.h> +#include <linux/fs.h> +#include <linux/jiffies.h> +#include <linux/module.h> +#include <linux/timer.h> +#include <linux/uaccess.h> +#include <linux/platform_device.h> +#include <linux/power_supply.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/pdata.h> +#include <linux/mfd/da9052/reg.h> + +/* STATIC CONFIGURATION */ +#define DA9052_BAT_CUTOFF_VOLT 2800 +#define DA9052_BAT_THRESHOLD 62000 +#define DA9052_BAT_CAPACITY_LIMIT_LOW 4 +#define DA9052_AVERAGE_SIZE 4 +#define DA9052_LOOK_UP_TABLE_SIZE 68 +#define DA9052_NO_OF_LOOKUP_TABLE 3 + +enum charger_type_enum { + DA9052_NOCHARGER = 1, + DA9052_CHARGER, +}; + +static const u16 temperature_lookup_ref[3] = {10, 25, 40}; +static u32 const vbat_vs_capacity_look_up[3][68][2] = { + /* For temperature 10 degree celisus*/ + { + {4082, 100}, {4036, 98}, + {4020, 96}, {4008, 95}, + {3997, 93}, {3983, 91}, + {3964, 90}, {3943, 88}, + {3926, 87}, {3912, 85}, + {3900, 84}, {3890, 82}, + {3881, 80}, {3873, 79}, + {3865, 77}, {3857, 76}, + {3848, 74}, {3839, 73}, + {3829, 71}, {3820, 70}, + {3811, 68}, {3802, 67}, + {3794, 65}, {3785, 64}, + {3778, 62}, {3770, 61}, + {3763, 59}, {3756, 58}, + {3750, 56}, {3744, 55}, + {3738, 53}, {3732, 52}, + {3727, 50}, {3722, 49}, + {3717, 47}, {3712, 46}, + {3708, 44}, {3703, 43}, + {3700, 41}, {3696, 40}, + {3693, 38}, {3691, 37}, + {3688, 35}, {3686, 34}, + {3683, 32}, {3681, 31}, + {3678, 29}, {3675, 28}, + {3672, 26}, {3669, 25}, + {3665, 23}, {3661, 22}, + {3656, 21}, {3651, 19}, + {3645, 18}, {3639, 16}, + {3631, 15}, {3622, 13}, + {3611, 12}, {3600, 10}, + {3587, 9}, {3572, 7}, + {3548, 6}, {3503, 5}, + {3420, 3}, {3268, 2}, + {2992, 1}, {2746, 0} + }, + /* For temperature 25 degree celisus */ + { + {4102, 100}, {4065, 98}, + {4048, 96}, {4034, 95}, + {4021, 93}, {4011, 92}, + {4001, 90}, {3986, 88}, + {3968, 87}, {3952, 85}, + {3938, 84}, {3926, 82}, + {3916, 81}, {3908, 79}, + {3900, 77}, {3892, 76}, + {3883, 74}, {3874, 73}, + {3864, 71}, {3855, 70}, + {3846, 68}, {3836, 67}, + {3827, 65}, {3819, 64}, + {3810, 62}, {3801, 61}, + {3793, 59}, {3786, 58}, + {3778, 56}, {3772, 55}, + {3765, 53}, {3759, 52}, + {3754, 50}, {3748, 49}, + {3743, 47}, {3738, 46}, + {3733, 44}, {3728, 43}, + {3724, 41}, {3720, 40}, + {3716, 38}, {3712, 37}, + {3709, 35}, {3706, 34}, + {3703, 33}, {3701, 31}, + {3698, 30}, {3696, 28}, + {3693, 27}, {3690, 25}, + {3687, 24}, {3683, 22}, + {3680, 21}, {3675, 19}, + {3671, 18}, {3666, 17}, + {3660, 15}, {3654, 14}, + {3647, 12}, {3639, 11}, + {3630, 9}, {3621, 8}, + {3613, 6}, {3606, 5}, + {3597, 4}, {3582, 2}, + {3546, 1}, {2747, 0} + }, + /* For temperature 40 degree celisus*/ + { + {4114, 100}, {4081, 98}, + {4065, 96}, {4050, 95}, + {4036, 93}, {4024, 92}, + {4013, 90}, {4002, 88}, + {3990, 87}, {3976, 85}, + {3962, 84}, {3950, 82}, + {3939, 81}, {3930, 79}, + {3921, 77}, {3912, 76}, + {3902, 74}, {3893, 73}, + {3883, 71}, {3874, 70}, + {3865, 68}, {3856, 67}, + {3847, 65}, {3838, 64}, + {3829, 62}, {3820, 61}, + {3812, 59}, {3803, 58}, + {3795, 56}, {3787, 55}, + {3780, 53}, {3773, 52}, + {3767, 50}, {3761, 49}, + {3756, 47}, {3751, 46}, + {3746, 44}, {3741, 43}, + {3736, 41}, {3732, 40}, + {3728, 38}, {3724, 37}, + {3720, 35}, {3716, 34}, + {3713, 33}, {3710, 31}, + {3707, 30}, {3704, 28}, + {3701, 27}, {3698, 25}, + {3695, 24}, {3691, 22}, + {3686, 21}, {3681, 19}, + {3676, 18}, {3671, 17}, + {3666, 15}, {3661, 14}, + {3655, 12}, {3648, 11}, + {3640, 9}, {3632, 8}, + {3622, 6}, {3616, 5}, + {3611, 4}, {3604, 2}, + {3594, 1}, {2747, 0} + } +}; + +struct da9052_battery { + struct da9052 *da9052; + struct power_supply psy; + int charger_type; + int status; + int health; +}; + +static inline int volt_reg_to_mV(int value) +{ + return ((value * 1000) / 512) + 2500; +} + +static inline int ichg_reg_to_mA(int value) +{ + return (value * 3900) / 1000; +} + +static int da9052_battery_read_end_current(struct da9052_battery *battery, + int *current_mA) +{ + int ret; + + if (battery->status == POWER_SUPPLY_STATUS_DISCHARGING) + return -EINVAL; + + ret = da9052_reg_read(battery->da9052, DA9052_ICHG_END_REG); + if (ret < 0) + return ret; + + *current_mA = ichg_reg_to_mA(ret & DA9052_ICHGEND_ICHGEND); + + return 0; +} + +static int da9052_battery_read_current(struct da9052_battery *battery, + int *current_mA) +{ + int ret; + + if (battery->status == POWER_SUPPLY_STATUS_DISCHARGING) + return -EINVAL; + + ret = da9052_reg_read(battery->da9052, DA9052_ICHG_AV_REG); + if (ret < 0) + return ret; + + *current_mA = ichg_reg_to_mA(ret & DA9052_ICHGAV_ICHGAV); + + return 0; +} + +static int da9052_battery_check_status(struct da9052_battery *battery, + int *status) +{ + uint8_t v[2] = {0, 0}; + uint8_t bat_status, chg_end; + int ret, chg_current, chg_end_current; + + ret = da9052_group_read(battery->da9052, DA9052_STATUS_A_REG, 2, v); + if (ret < 0) + return ret; + + bat_status = v[0]; + chg_end = v[1]; + + /* Preference to WALL(DCIN) charger unit */ + if (((bat_status & DA9052_STATUSA_DCINSEL) && + (bat_status & DA9052_STATUSA_DCINDET)) + || + ((bat_status & DA9052_STATUSA_VBUSSEL) && + (bat_status & DA9052_STATUSA_VBUSDET)) + ) { + battery->charger_type = DA9052_CHARGER; + + /* If charging end flag is set and Charging current is greater + * than charging end limit then battery is charging + */ + if ((chg_end & DA9052_STATUSB_CHGEND) != 0) { + ret = da9052_battery_read_current(battery, + &chg_current); + if (ret < 0) + return ret; + ret = da9052_battery_read_end_current(battery, + &chg_end_current); + if (ret < 0) + return ret; + + if (chg_current >= chg_end_current) + battery->status = POWER_SUPPLY_STATUS_CHARGING; + else + battery->status = + POWER_SUPPLY_STATUS_NOT_CHARGING; + } + /* If Charging end flag is cleared then battery is charging */ + else + battery->status = POWER_SUPPLY_STATUS_CHARGING; + } else if (bat_status & DA9052_STATUSA_DCINDET || + bat_status & DA9052_STATUSA_VBUSDET) { + battery->charger_type = DA9052_CHARGER; + battery->status = POWER_SUPPLY_STATUS_NOT_CHARGING; + } else { + battery->charger_type = DA9052_NOCHARGER; + battery->status = POWER_SUPPLY_STATUS_DISCHARGING; + } + + if (status != NULL) + *status = battery->status; + return 0; +} + +static int da9052_battery_read_volt(struct da9052_battery *battery, + int *volt_mV) +{ + int voltage; + + voltage = da9052_adc_manual_read(battery->da9052, + DA9052_ADC_MAN_MUXSEL_VBAT); + if (voltage < 0) + return voltage; + + *volt_mV = volt_reg_to_mV(voltage); + + return 0; +} + +static int da9052_battery_check_presence(struct da9052_battery *battery, + int *illegal) +{ + int bat_temp; + + bat_temp = da9052_adc_temperature_read(battery->da9052); + if (bat_temp < 0) + return bat_temp; + + if (bat_temp > DA9052_BAT_THRESHOLD) + *illegal = 1; + else + *illegal = 0; + + return 0; +} + +static int interpolated(int vbat_lower, int vbat_upper, int level_lower, + int level_upper, int bat_voltage) +{ + int temp; + + temp = ((level_upper - level_lower) * 1000) / (vbat_upper - vbat_lower); + temp = level_lower + (((bat_voltage - vbat_lower) * temp) / 1000); + + return temp; +} + +unsigned char select_temperature(unsigned char temp_index, int bat_temperature) +{ + int temp_temperature; + + temp_temperature = (temperature_lookup_ref[temp_index] + + temperature_lookup_ref[temp_index + 1]) / 2; + + if (bat_temperature >= temp_temperature) { + temp_index += 1; + return temp_index; + } else + return temp_index; +} + +static int da9052_battery_read_capacity(struct da9052_battery *battery, + int *capacity) +{ + int bat_temperature, bat_voltage; + int vbat_lower, vbat_upper, level_upper, level_lower; + int ret, flag, index, access_index = 0; + + ret = da9052_battery_read_volt(battery, &bat_voltage); + if (ret < 0) + return ret; + + bat_temperature = da9052_adc_temperature_read(battery->da9052); + if (bat_temperature < 0) + return bat_temperature; + + for (index = 0; index < (DA9052_NO_OF_LOOKUP_TABLE - 1); index++) { + if (bat_temperature <= temperature_lookup_ref[0]) { + access_index = 0; + break; + } else if (bat_temperature > + temperature_lookup_ref[DA9052_NO_OF_LOOKUP_TABLE]) { + access_index = DA9052_NO_OF_LOOKUP_TABLE - 1; + break; + } else if ((bat_temperature >= temperature_lookup_ref[index]) && + (bat_temperature >= temperature_lookup_ref[index + 1] + )) { + access_index = select_temperature(index, + bat_temperature); + break; + } + } + if (bat_voltage >= vbat_vs_capacity_look_up[access_index][0][0]) { + *capacity = 100; + return 0; + } + if (bat_voltage <= vbat_vs_capacity_look_up[access_index] + [DA9052_LOOK_UP_TABLE_SIZE - 1][0]) { + *capacity = 0; + return 0; + } + flag = 0; + + for (index = 0; index < (DA9052_LOOK_UP_TABLE_SIZE-1); index++) { + if ((bat_voltage <= + vbat_vs_capacity_look_up[access_index][index][0]) && + (bat_voltage >= + vbat_vs_capacity_look_up[access_index][index + 1][0])) { + vbat_upper = + vbat_vs_capacity_look_up[access_index][index][0]; + vbat_lower = + vbat_vs_capacity_look_up[access_index][index + 1][0]; + level_upper = + vbat_vs_capacity_look_up[access_index][index][1]; + level_lower = + vbat_vs_capacity_look_up[access_index][index + 1][1]; + flag = 1; + break; + } + } + if (!flag) + return -EIO; + + *capacity = interpolated(vbat_lower, vbat_upper, level_lower, + level_upper, bat_voltage); + + return 0; +} + +static int da9052_battery_check_health(struct da9052_battery *battery, + int *health) +{ + int ret, bat_illegal, capacity; + + ret = da9052_battery_check_presence(battery, &bat_illegal); + if (ret < 0) + return ret; + + if (bat_illegal) { + battery->health = POWER_SUPPLY_HEALTH_UNKNOWN; + return 0; + } + + if (battery->health != POWER_SUPPLY_HEALTH_OVERHEAT) { + ret = da9052_battery_read_capacity(battery, &capacity); + if (ret < 0) + return ret; + if (capacity < DA9052_BAT_CAPACITY_LIMIT_LOW) + battery->health = POWER_SUPPLY_HEALTH_DEAD; + else + battery->health = POWER_SUPPLY_HEALTH_GOOD; + } + + *health = battery->health; + + return 0; +} + +static irqreturn_t da9052_bat_irq(int irq, void *data) +{ + struct da9052_battery *battery = (struct da9052_battery *)data; + + irq -= battery->da9052->irq_base; + + if (irq == DA9052_IRQ_CHGEND) + battery->status = POWER_SUPPLY_STATUS_FULL; + else + da9052_battery_check_status(battery, NULL); + + if (irq == DA9052_IRQ_CHGEND || irq == DA9052_IRQ_DCIN || + irq == DA9052_IRQ_VBUS || irq == DA9052_IRQ_TBAT) { + power_supply_changed(&battery->psy); + } + + return IRQ_HANDLED; +} + +static int da9052_bat_get_property(struct power_supply *psy, + enum power_supply_property psp, + union power_supply_propval *val) +{ + int ret, illegal; + struct da9052_battery *battery = container_of(psy, + struct da9052_battery, psy); + + ret = da9052_battery_check_presence(battery, &illegal); + if (ret < 0) + return ret; + + if (illegal && psp != POWER_SUPPLY_PROP_PRESENT) + return -ENODEV; + + switch (psp) { + case POWER_SUPPLY_PROP_STATUS: + ret = da9052_battery_check_status(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_ONLINE: + val->intval = + (battery->charger_type == DA9052_NOCHARGER) ? 0 : 1; + break; + case POWER_SUPPLY_PROP_PRESENT: + ret = da9052_battery_check_presence(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_HEALTH: + ret = da9052_battery_check_health(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: + val->intval = DA9052_BAT_CUTOFF_VOLT * 1000; + break; + case POWER_SUPPLY_PROP_VOLTAGE_AVG: + ret = da9052_battery_read_volt(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_CURRENT_AVG: + ret = da9052_battery_read_current(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_CAPACITY: + ret = da9052_battery_read_capacity(battery, &val->intval); + break; + case POWER_SUPPLY_PROP_TEMP: + val->intval = da9052_adc_temperature_read(battery->da9052); + ret = val->intval; + break; + case POWER_SUPPLY_PROP_TECHNOLOGY: + val->intval = POWER_SUPPLY_TECHNOLOGY_LION; + break; + default: + return -EINVAL; + } + return ret; +} + +static enum power_supply_property da9052_bat_props[] = { + POWER_SUPPLY_PROP_STATUS, + POWER_SUPPLY_PROP_ONLINE, + POWER_SUPPLY_PROP_PRESENT, + POWER_SUPPLY_PROP_HEALTH, + POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, + POWER_SUPPLY_PROP_VOLTAGE_AVG, + POWER_SUPPLY_PROP_CURRENT_AVG, + POWER_SUPPLY_PROP_CAPACITY, + POWER_SUPPLY_PROP_TEMP, + POWER_SUPPLY_PROP_TECHNOLOGY, +}; + +static struct power_supply template_battery = { + .name = "da9052-bat", + .type = POWER_SUPPLY_TYPE_BATTERY, + .properties = da9052_bat_props, + .num_properties = ARRAY_SIZE(da9052_bat_props), + .get_property = da9052_bat_get_property, +}; + +static const char *da9052_bat_irqs[] = { + "BATT TEMP", + "DCIN DET", + "DCIN REM", + "VBUS DET", + "VBUS REM", + "CHG END", +}; + +static s32 __devinit da9052_bat_probe(struct platform_device *pdev) +{ + struct da9052_pdata *pdata; + struct da9052_battery *battery; + int ret, irq, i; + + battery = kzalloc(sizeof(struct da9052_battery), GFP_KERNEL); + if (!battery) + return -ENOMEM; + + battery->da9052 = dev_get_drvdata(pdev->dev.parent); + pdata = battery->da9052->dev->platform_data; + + battery->psy = template_battery; + if (pdata != NULL && pdata->use_for_apm) + battery->psy.use_for_apm = pdata->use_for_apm; + battery->charger_type = DA9052_NOCHARGER; + battery->status = POWER_SUPPLY_STATUS_UNKNOWN; + battery->health = POWER_SUPPLY_HEALTH_UNKNOWN; + + for (i = 0; i < ARRAY_SIZE(da9052_bat_irqs); i++) { + irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]); + ret = request_threaded_irq(battery->da9052->irq_base + irq, + NULL, da9052_bat_irq, + IRQF_TRIGGER_LOW | IRQF_ONESHOT, + da9052_bat_irqs[i], battery); + if (ret != 0) { + dev_err(battery->da9052->dev, + "DA9052 failed to request %s IRQ %d: %d\n", + da9052_bat_irqs[i], irq, ret); + goto err; + } + } + + ret = power_supply_register(&pdev->dev, &battery->psy); + if (ret) + goto err; + + return 0; + +err: + for (; i >= 0; i--) { + irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]); + free_irq(irq, battery); + } + kfree(battery); + return ret; +} +static int __devexit da9052_bat_remove(struct platform_device *pdev) +{ + int i, irq; + struct da9052_battery *battery = platform_get_drvdata(pdev); + + for (i = 0; i < ARRAY_SIZE(da9052_bat_irqs); i++) { + irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]); + free_irq(irq, battery); + } + power_supply_unregister(&battery->psy); + + return 0; +} + +static struct platform_driver da9052_bat_driver = { + .probe = da9052_bat_probe, + .remove = __devexit_p(da9052_bat_remove), + .driver = { + .name = "da9052-bat", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_bat_init(void) +{ + return platform_driver_register(&da9052_bat_driver); +} +module_init(da9052_bat_init); + +static void __exit da9052_bat_exit(void) +{ + platform_driver_unregister(&da9052_bat_driver); +} +module_exit(da9052_bat_exit); + +MODULE_DESCRIPTION("DA9052 BAT Device Driver"); +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-bat");

12 years, 6 months

[RFC PATCH 0/11] ARM: cpu topology Cortex-A9

by Vincent Guittot

The sched_mc feature has been originally designed to improve power consumption of multi-package system and several architecture functions are available to tune the topology and the scheduler's parameters when scheduler rebuilds the sched_domain hierarchy (change the sched_mc_power_savings level). This patches series is a trial to improve the power consumption of dual and quad cortex-A9 when the sched_mc_power_savings is set to 2. The following patch's policy is to accept up to 4 threads (can be configured) in the run queue of a core before starting to load balance if cpu runs at low frequencies but to accept only 1 thread for high frequencies, which is the normal behaviour. The goal is to use only one cpu in light load situation and both cpu in heavy load situation Patches [1-3] modify the ARM cpu topology according to sched_mc_power_savings value and Cortex id Patch [4] enables ARCH_POWER feature of the scheduler Patch [5] adds ARCH_POWER function for ARM platform Patches [6-7] modify the cpu_power of CA-9 according to sched_mc_power_savings' level and current frequency. The main goal is to increase the capacity of a core when using low cpu frequency in order to pull tasks on this core. Note that this behaviour is not really advised but it can be seen as an intermediate step between the use of cpu hotplug (which is not a power saving feature) and a new load balancer which will take into account low load situation on dual core. Patch [8] ensures that cpu0 is used in priority when only one CPU is running Patch [9] adds some debugfs interface for test purpose Patch [10] ensures that the cpu_power will be update periodically Patch [11] fixes an issue around the trigger of ilb. TODO list: -remove useless start of ilb when the core has capacity. -add a method (DT, sysfs, ...) to set threshold for using 1 or 2 cpus for dual CA-9 -irq balancing The tests hereafter have been done on a u8500 with kernel linaro-3.1. They check that there is no obvious lost of performance when sched_mc=2. sysbench --test=cpu --num-threads=12 --max-time=20 run Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug total number of events: 665 664 336 per-request statistics: min: 92.68ms 70.53ms 618.89ms avg: 361.75ms 361.38ms 725.29ms max: 421.08ms 420.73ms 840.74ms approx. 95 percentile: 402.28ms 390.53ms 760.17ms sysbench --test=threads --thread-locks=9 --num-threads=12 --max-time=20 run Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug total number of events: 10000 10000 3129 per-request statistics: min: 1.62ms 1.70ms 13.16ms avg: 22.23ms 21.87ms 76.77ms max: 153.52ms 133.99ms 173.82ms approx. 95 percentile: 54.12ms 52.65ms 136.32ms sysbench --test=threads --thread-locks=2 --num-threads=3 --max-time=20 run Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug total number of events: 10000 10000 10000 per-request statistics: min: 1.38ms 1.38ms 5.70ms avg: 4.67ms 5.37ms 11.85ms max: 36.84ms 32.42ms 32.58ms approx. 95 percentile: 14.34ms 12.89ms 21.30ms cyclictest -q -t -D 20 Only one cpu is used during this test when sched_mc=2 whereas both cpu are used when sched_mc=0 Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug Avg, Max: 15, 434 19, 2145 17, 3556 Avg, Max: 14, 104 19, 1686 17, 3593 Regards, Vincent

12 years, 6 months

[RFC PATCH 0/4] ARM: Exynos4: Thermal solution using Linux thermal infrstructure

by Amit Daniel Kachhap

This RFC version of the patch set is intended to share the current work about providing a thermal solution using Linux thermal infrastructure. The closest driver which has the same features and not using acpi layer is drivers/platform/x86/acerhdf.c. For the ARM world there is no clarity for placing such files so currently I have placed the temperature sensor driver and a binding layer for cooling device, thermal zone and core thermal interfaces inside staging directory. Feel free to comment about the implementation, the directory structure and the shortcomings. Amit Daniel Kachhap (4): ARM: Exynos4: Add thermal sensor driver for samsung exynos4 platform. ARM: Exynos4: Add thermal sensor driver platform device support ARM: Exynos4: Enable thermal sensor driver for origen board ARM: Exynos4: Add thermal interface support for linux thermal layer arch/arm/mach-exynos4/Kconfig | 5 + arch/arm/mach-exynos4/Makefile | 3 +- arch/arm/mach-exynos4/dev-tmu.c | 71 +++ arch/arm/mach-exynos4/include/mach/exynos4-tmu.h | 75 ++++ arch/arm/mach-exynos4/include/mach/irqs.h | 3 + arch/arm/mach-exynos4/include/mach/map.h | 1 + arch/arm/mach-exynos4/include/mach/regs-tmu.h | 58 +++ .../mach-exynos4/include/mach/thermal_interface.h | 26 ++ arch/arm/mach-exynos4/mach-origen.c | 10 + arch/arm/plat-samsung/include/plat/devs.h | 2 + drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/thermal_exynos4/Kconfig | 12 + drivers/staging/thermal_exynos4/Makefile | 5 + drivers/staging/thermal_exynos4/sensor/Kconfig | 14 + drivers/staging/thermal_exynos4/sensor/Makefile | 4 + .../thermal_exynos4/sensor/exynos4210_tmu.c | 465 ++++++++++++++++++++ .../staging/thermal_exynos4/thermal_interface.c | 382 ++++++++++++++++ 18 files changed, 1138 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-exynos4/dev-tmu.c create mode 100644 arch/arm/mach-exynos4/include/mach/exynos4-tmu.h create mode 100644 arch/arm/mach-exynos4/include/mach/regs-tmu.h create mode 100644 arch/arm/mach-exynos4/include/mach/thermal_interface.h create mode 100644 drivers/staging/thermal_exynos4/Kconfig create mode 100644 drivers/staging/thermal_exynos4/Makefile create mode 100644 drivers/staging/thermal_exynos4/sensor/Kconfig create mode 100644 drivers/staging/thermal_exynos4/sensor/Makefile create mode 100644 drivers/staging/thermal_exynos4/sensor/exynos4210_tmu.c create mode 100644 drivers/staging/thermal_exynos4/thermal_interface.c

12 years, 6 months

Proposal for a low-level Linux display framework

by Tomi Valkeinen

Hi, I am the author of OMAP display driver, and while developing it I've often felt that there's something missing in Linux's display area. I've been planning to write a post about this for a few years already, but I never got to it. So here goes at last! --- First I want to (try to) describe shortly what we have on OMAP, to give a bit of a background for my point of view, and to have an example HW. The display subsystem (DSS) hardware on OMAP handles only showing pixels on a display, so it doesn't contain anything that produces pixels like 3D stuff or accelerated copying. All it does is fetch pixels from SDRAM, possibly do some modifications for them (color format conversions etc), and output them to a display. The hardware has multiple overlays, which are like hardware windows. They fetch pixels from SDRAM, and output them in a certain area on the display (possibly with scaling). Multiple overlays can be composited into one output. So we may have something like this, when all overlays read pixels from separate areas in the memory, and all overlays are on LCD display: .-----. .------. .------. | mem |-------->| ovl0 |-----.---->| LCD | '-----' '------' | '------' .-----. .------. | | mem |-------->| ovl1 |-----| '-----' '------' | .-----. .------. | .------. | mem |-------->| ovl2 |-----' | TV | '-----' '------' '------' The LCD display can be rather simple one, like a standard monitor or a simple panel directly connected to parallel RGB output, or a more complex one. A complex panel needs something else than just turn-it-on-and-go. This may involve sending and receiving messages between OMAP and the panel, but more generally, there's need to have custom code that handles the particular panel. And the complex panel is not necessarily a panel at all, it may be a buffer chip between OMAP and the actual panel. The software side can be divided into three parts: the lower level omapdss driver, the lower level panel drivers, and higher level drivers like omapfb, v4l2 and omapdrm. The omapdss driver handles the OMAP DSS hardware, and offers a kernel internal API which the higher level drivers use. The omapdss does not know anything about fb or drm, it just offers core display services. The panel drivers handle particular panels/chips. The panel driver may be very simple in case of a conventional display, basically doing pretty much nothing, or bigger piece of code, handling communication with the panel. The higher level drivers handle buffers and tell omapdss things like where to find the pixels, what size the overlays should be, and use the omapdss API to turn displays on/off, etc. --- There are two things that I'm proposing to improve the Linux display support: First, there should be a bunch of common video structs and helpers that are independent of any higher level framework. Things like video timings, mode databases, and EDID seem to be implemented multiple times in the kernel. But there shouldn't be anything in those things that depend on any particular display framework, so they could be implemented just once and all the frameworks could use them. Second, I think there could be use for a common low level display framework. Currently the lower level code (display HW handling, etc.) and higher level code (buffer management, policies, etc) seem to be usually tied together, like the fb framework or the drm. Granted, the frameworks do not force that, and for OMAP we indeed have omapfb and omapdrm using the lower level omapdss. But I don't see that it's anything OMAP specific as such. I think the lower level framework could have components something like this (the naming is OMAP oriented, of course): overlay - a hardware "window", gets pixels from memory, possibly does format conversions, scaling, etc. overlay compositor - composes multiple overlays into one output, possibly doing things like translucency. output - gets the pixels from overlay compositor, and sends them out according to particular video timings when using conventional video interface, or via any other mean when using non-conventional video buses like DSI command mode. display - handles an external display. For conventional displays this wouldn't do much, but for complex ones it does whatever needed by that particular display. This is something similar to what DRM has, I believe. The biggest difference is that the display can be a full blown driver for a complex piece of HW. This kind of low level framework would be good for two purposes: 1) I think it's a good division generally, having the low level HW driver separate from the higher level buffer/policy management and 2) fb, drm, v4l2 or any possible future framework could all use the same low level framework. --- Now, I'm quite sure the above framework could work quite well with any OMAP like hardware, with unified memory (i.e. the video buffers are in SDRAM) and 3D chips and similar components are separate. But what I'm not sure is how desktop world's gfx cards change things. Most probably all the above components can be found from there also in some form, but are there some interdependencies between 3D/buffer management/something else and the video output side? This was a very rough and quite short proposal, but I'm happy to improve and extend it if it's not totally shot down. Tomi

12 years, 6 months

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

12 years, 6 months

Fwd: Device Tree for Android

by Botao Sun

Hi, Let me forward this to more people. :) I'm still grabbing the relevant information for this, so if anyone has ideas on it, welcome and reply emails to me! This is currently subscriber list: Bernhard Rosenkraenzer Dan Trevino Deepak Saxena Frans Gifford Grant Likely John Stultz Kwanghyun LA Marcus Lorentzon Mathieu Poirier Patrik Ryd Sangwook Lee Tony Mansson Yejin Moon Zach Pfeffer Thank you all! BR Botao Sun ---------- Forwarded message ---------- From: Tony Mansson <tony.mansson(a)linaro.org> Date: Fri, Oct 28, 2011 at 2:38 AM Subject: Device Tree for Android To: Deepak Saxena <dsaxena(a)linaro.org>, Grant Likely < grant.likely(a)linaro.org> Cc: Botao Sun <Botao.Sun(a)linaro.org> Hello, Please note that there will be a session at Connect titled "Device Tree for Android" headed by Botao Sun from the Android Platform Team. https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.… At the time of writing the session is scheduled for Tuesday at 10:00. Your presence would be appreciated. BR, Tony Mansson

12 years, 6 months

Re: Debian GNU/Linux on tablet hardware

by Zygmunt Krynicki

W dniu 28.10.2011 17:46, Jeremiah Foster pisze: >>> >>> Android's Linux kernels are supported (maintained?) by Linaro. >> >> With my Linaro hat on I must object. Depending on what you meant the statement above is either highly inaccurate or simply untrue. > > Hence the question mark. :) I think what I originally meant is that we don't focus solely on Android. "Improved" is the word I would use, that implies neither support nor maintenance as we are between the vendors (that are also part of Linaro) and upstream kernel community (that we are a part of) and we have no control of either side and their actions. As to what we do check our FAQ (http://www.linaro.org/faqs/) and read on. >> Android kernel situation is complicated and varies per board/SoC. What Linaro does is try to upstream and unify the kernel for Linaro member companies SoCs. > > What does that mean in practice? Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev(a)lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet. As for your question, read on. A lot of ARM devices have a BSP kernel (android or not) that is prepared by some 3rd party (sometimes also by the vendor themselves if the device is a clone of the reference design) and that kernel is generally not pushed upstream. This affects, by far, the vast majority of devices out there (I'd say that nothing gets pushed by those companies simply because their work mode does not require such a step - we are working on educating them in the benefits of working both towards products and common code base). The ARM tree in the upstream kernel is, again, by far, the largest of all the other architectures. If I remember correctly it is in fact larger than *all* the other trees combined. The reasons for this are complicated but can be generally simplified to code duplication between the different devices and greater diversity in the actual hardware as compared to other platforms. To get ARM Linux healthy we need to reduce that clutter and make sure that support for the latest and greatest hardware is upstream quickly and the code is being actively maintained by everyone. >> This is far from finished and uniform. The "BSP" kernel that hardware vendors provide is not supported by Linaro and in fact often contains code that cannot go upstream. > > What does it use this proprietary code for? To know the APIs or to get other hardware interface info? Isn't that a little risky? Won't proprietary, and potentially patented IP leak into the Linaro work? (Not that I believe in IP.) The term proprietary is a bit misleading, the code IS released as GPL. It is simply there to support some parts (often userspace or "firmware") that is not open sourced and cannot be for all practical considerations. As for the patches in general, there are different reasons why they are not suitable for being proposed and included upstream: 1) Shabby code, against old trees, copy-pasted from another similar device, maintenance hell. This is, by my unqualified judgment, the vast majority of the problem. 2) Code that has no good place in the kernel just yet because the kernel interfaces are insufficient for the extremely complicated world of ARM SoCs. Off the top of my, unqualified, head: power management, memory management, everything related to graphics and probably many more. Here the reason for not being upstream is that there is no consensus on how to do something (how to support a certain class of SoC components) that could be applied to many vendors and non-arm world as well. Here the people that write the BSP cannot solve the problem and just implement their own solution to meet the deadline. Such code is often very good but there are many similar solutions that are quite nontrivial to merge into one sensible codebase. One such example is memory management where we have no less than 3 or 4 competing interfaces from various companies and there is a working group inside Linaro and the greater Linux community that tries to solve this problem. 3) Bits that enable proprietary userspace drivers. The reasons are obvious. This could be related to lots of different things, not only graphics as people often think. IP and software edge (optimizations that make otherwise identical hardware perform better than competition) is probably a big motivation here. The IP protection is not only used as in "don't steal our stuff" but rather "hey, with this being binary it is harder to prove that we violate a specific patent you have". In retrospective this is a thing those companies obviously need. Just look at how many Android handset vendors pay to, for example, Microsoft, for patents that allegedly apply there. The world of graphics is riddled with patents and I'm sure that a big money-laden hardware vendor is a good target for whoever owns the patents. >> Linaro has several trees, including a grand unification tree that tries to support all the member companies chips in one tree (and one binary, thanks to device trees) but this effort is years away (my personal estimate, I don't speak for the organization). In addition we have several trees for normal/androidized kernel for each board. In the latest 2011.10 release hardware was not supported in 100% on any board that I'm aware of. >> >> Having said that the term "supported" seems inappropriate to me. We do work on those boards though. > > How would you define it? By "work" I meant "we are *working* on making the kernel and userspace on those boards better in each release". Better is shared amongst: 1) More patches landed upstream, thus less delta. 2) Less duplication within the kernel (better code), more device tree usage, closer to having one kernel binary that supports several different boards. 3) Better power management, stability, performance, more features, bells and whistles. 4) Less delta from the android variant to the normal variant. More discussion and more consensus on how to join the two worlds. And let's not forget, my own personal favorite, more validation. The code is tested both manually and automatically and the scope, coverage and quality is pushed forward each time. >>> Anything that runs Android can run GNU/Linux. >> >> This is a gross oversimplification IMHO. You usually get androidized BSP kernel from a few months/years ago with binary parts that have no corresponding source code. Good luck booting vanilla kernel there. > > But it appears to me that all the official boards that are targets for Linaro can run a vanilla kernel, is that not the case? If not, what BSP stuff are you referring to - graphics acceleration? No I don't think that is the case. A quick glance at http://git.linaro.org/gitweb will show you how many trees we have. Except for the explicit upstream trees that Nico maintains none of the important changes in other trees are upstream today (at least not yet). Even the Linaro various kernels (which are _not_ the BSP kernels) fail to work sensibly on all of the boards today. Next-gen boards are usually the ones with weakest support (although that is rapidly changing, thanks to what we are doing). Often most primitive board features work (like, it kind of boots with a specific boot loader and the CPU runs) but anything you definitely want those boards to do: power management, stability, sound, graphics, 3D & multimedia, wifi/bluetooth, FM radio, GPS(?), DSP suppoet, ARMv7 optimizations, is simply not there. Best regards ZK PS: I think that you should ask those questions on @linaro-dev. I could be talking nonsense here and the people that really know simply did not see this message. Therefore I'm cross-posting to linaro-dev.

12 years, 6 months

[ANN] 11.10 Pre-built images are available

by Andy Doan

I've just finished uploading pre-built images for the 11.10 release to: http://releases.linaro.org/images/11.10/oneiric/ These are built with default options from Linaro Media Create to pre-set sizes. You can install these with 4 simple commands: $ SDCARD=/dev/sdb $ IMGFILE=overo-nano.img $ gunzip ${IMGFILE}.gz $ dd bs=4k if=${IMGFILE} of=${SDCARD} -andy

12 years, 6 months

[ANN] Android Build downloads and other improvements

by Paul Sokolovsky

Hello, There were few user-facing improvements for https://android-build.linaro.org/ , Linaro Android Build System, from which can be downloaded daily builds of Android components (platform, toolchain): 1. HTTP downloads were enabled. It was long-standing feature request, and brings number of improvements to user experience and system scalability: a) With 100Mb+ downloads android-build.linaro.org provides, going plain HTTP instead of SSL improves download speed pretty well. b) Taking into account that downloads are server by not very powerful EC2 instance, alleviating it from SSL number-crunching improve concurrent download speed and build performance. c) Using plain HTTP gets around SSL certificate issues, the need to do extra click-thru in browser or use obscure options for wget. 2. HTTP downloads made default for the Build Frontend. Instead of documenting HTTP download link on some obscure web page, they were made default when browsing build results from https://android-build.linaro.org , e.g.: https://android-build.linaro.org/builds/~linaro-android/staging-panda/ (Please note that all older links will keep working. Underlying Jenkins instance also keeps using https:// links). 3. MD5SUMS are available for platform downloads. Now it's easy to verify integrity of downloads using well-known convention of MD5SUMS files. Whole download and integrity checking can be scripted as: wget -r -nd http://android-build.linaro.org/builds/~linaro-android/staging-panda/65/tar… md5sum -c MD5SUMS 4. Links to easily access build logs in several formats added. Last milestone, we enabled Jenkins Log Parser plugin, which allowed to get quickly to the location of errors within 20MB build log file. However, it was available only from within Jenkins. Now, links to the most useful log browsing pages were added directly to frontend's build page, following concept that frontend page should make the most useful build information available and developers' fingertips. Now there're (under "Log" subsection on the page): * Parsed - parsed log mentioned above, providing quick jump to error locations and stats about a build * Tail - Last 500KB or so of the log, which oftentimes contain error. With one click, entire log can be browsed, with all lines still nicely wrapped. * Raw - plain-text log, as available before. This is mostly suitable for download and local view, as lines are not wrapped in most browsers when viewing online. See https://android-build.linaro.org/builds/~linaro-android/staging-panda/#buil… for example. -- 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

12 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev October 2011