linaro-dev July 2011

linaro-dev@lists.linaro.org

107 participants
163 discussions

Re: ppas, version numbers, releases and validation.linaro.org

by Paul Larson

(If you reply, reply to this one, not the previous message I sent, this one fixes the linaro-dev email address) On Mon, Jul 11, 2011 at 4:35 AM, Zygmunt Krynicki < zygmunt.krynicki(a)linaro.org> wrote: > In short: ~zygaN is the thing we can increment. We should KEEP and perhaps > change the name to ~lava (but this has to be coordinated as ~lava < ~zyga. > There are three possible scenarios which this system correctly handles: > > Right, but we can make that change anytime the upstream version gets bumped. So if it has an upstream version component that gets bumped, then feel free to change over to the ~lava designation as soon as you make a release that bumps the upstream version. Otherwise, if it's a component that uses YYYY.MM <http://yyyy.mm/> only, then we will wait until the 2011.07 release later this month to switch. -Paul Larson

13 years, 3 months

ppas, version numbers, releases and validation.linaro.org

by Michael Hudson-Doyle

Hi Paul & Zygmunt (& others), I spent a while today fixing a couple of bugs in lava-tool and in the packaging of lava-server, and was wondering what the process should be for getting them into the ~linaro-validation ppa and onto v.l.o (although there's no particular urgency in getting these precise fixes deployed, there will be changes that are more urgent). In some sense these are basic debian packaging questions I guess. But my understanding of the process is that it should go like this: If there are upstream changes, make a new release (update the version in __init__.py, tag the branch, make an sdist and upload it to pypi). Then (whether there is an upstream change or not) it should be uploaded to a PPA. I think the part here that I don't really get is basically how to use bzr build-deb in practice. But I've just found http://jameswestby.net/bzr/builddeb/user_manual/merge.html so I think I should read that first :) Another question I have is around version numbers. Currently we're using version numbers like 0.2-0ubuntu0~zyga1. I don't really see why the "zyga" is in there :) I think simply dropping the zyga and using versions like 0.2-0ubuntu0~1 would be fine, or if we want to know who uploaded a particular version we can use things like 0.2-0ubuntu0~2mwhudson. Finally, I think that we should be triggerhappy about releases, and so going through the above process shouldn't take very long. I guess lava-dev-tool can help here. Cheers, mwh

13 years, 3 months

[Patch 5/11] Regulator: DA9052 regulator support v2

by ashishj3

The DA9052 PMIC has below featured regulators:- 4 DVS Buck converters 0.5V - 3.6V upto 1Amp. 10 Programmable LDO's High PSSR, 1% accuracy. This patch support all the DA9052 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> CC: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- 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 | 544 ++++++++++++++++++++++++++++++++++ 3 files changed, 552 insertions(+), 0 deletions(-) create mode 100755 drivers/regulator/da9052-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index fa61fe2..ae80461 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -167,6 +167,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 regulators" + depends on PMIC_DA9052 + help + Say y here to support the BUCKs and LDOs regulators found on + Dialog Semiconductor DA9052 PMIC. + config REGULATOR_PCF50633 tristate "PCF50633 regulator driver" depends on MFD_PCF50633 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 8cb6d0d..3738361 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -28,6 +28,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 100755 index 0000000..e7126d7 --- /dev/null +++ b/drivers/regulator/da9052-regulator.c @@ -0,0 +1,544 @@ +/* +* 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 + +/* Buck current limits */ +#define DA9052_BUCK_CURRENT_LIMIT_700mA 0 +#define DA9052_BUCK_CURRENT_LIMIT_800mA 1 +#define DA9052_BUCK_CURRENT_LIMIT_1000mA 2 +#define DA9052_BUCK_CURRENT_LIMIT_1200mA 3 + +/* Bit masks */ +#define DA9052_BUCK_ILIM_MASK_EVEN 0x3F +#define DA9052_BUCK_ILIM_MASK_ODD 0xF3 + +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->min_uV || min_uV > info->max_uV) + return -EINVAL; + if (max_uV < info->min_uV || max_uV > info->max_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); +} + +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; + + 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; + + return 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; + + if (min_uA < 700000 || min_uA > 1200000) + return -EINVAL; + if (max_uA < 700000 || max_uA > 1200000) + return -EINVAL; + + if (min_uA == 700000) + reg_val = DA9052_BUCK_CURRENT_LIMIT_700mA; + else if (min_uA <= 800000) + reg_val = DA9052_BUCK_CURRENT_LIMIT_800mA; + else if (min_uA <= 1000000) + reg_val = DA9052_BUCK_CURRENT_LIMIT_1000mA; + else if (min_uA <= 1200000) + reg_val = DA9052_BUCK_CURRENT_LIMIT_1200mA; + + /* 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 (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; + + *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 >= DA9052_CONST_3uV) + *selector = DA9052_CONST_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), +}; + +static inline struct da9052_regulator_info *find_regulator_info(int id) +{ + struct da9052_regulator_info *info; + int i; + + for (i = 0; i < ARRAY_SIZE(da9052_regulator_info); i++) { + info = &da9052_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->info = find_regulator_info(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");

13 years, 3 months

[PATCH v5] mmc: documentation of mmc non-blocking request usage and design.

by Per Forlin

Documentation about the background and the design of mmc non-blocking. Host driver guidelines to minimize request preparation overhead. Signed-off-by: Per Forlin <per.forlin(a)linaro.org> Acked-by: Randy Dunlap <rdunlap(a)xenotime.net> --- ChangeLog: v2: - Minor updates after proofreading comments from Chris v3: - Minor updates after more comments from Chris v4: - Minor updates after comments from Randy v5: - Fixed one more comment and Acked-by from Randy Documentation/mmc/00-INDEX | 2 + Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/mmc/mmc-async-req.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index 93dd7a7..a9ba672 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -4,3 +4,5 @@ mmc-dev-attrs.txt - info on SD and MMC device attributes mmc-dev-parts.txt - info on SD and MMC device partitions +mmc-async-req.txt + - info on mmc asynchronous requests diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt new file mode 100644 index 0000000..b7a52ea --- /dev/null +++ b/Documentation/mmc/mmc-async-req.txt @@ -0,0 +1,86 @@ +Rationale +========= + +How significant is the cache maintenance overhead? +It depends. Fast eMMC and multiple cache levels with speculative cache +pre-fetch makes the cache overhead relatively significant. If the DMA +preparations for the next request are done in parallel with the current +transfer, the DMA preparation overhead would not affect the MMC performance. +The intention of non-blocking (asynchronous) MMC requests is to minimize the +time between when an MMC request ends and another MMC request begins. +Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and +dma_unmap_sg are processing. Using non-blocking MMC requests makes it +possible to prepare the caches for next job in parallel with an active +MMC request. + +MMC block driver +================ + +The issue_rw_rq() in the MMC block driver is made non-blocking. +The increase in throughput is proportional to the time it takes to +prepare (major part of preparations are dma_map_sg and dma_unmap_sg) +a request and how fast the memory is. The faster the MMC/SD is +the more significant the prepare request time becomes. Roughly the expected +performance gain is 5% for large writes and 10% on large reads on a L2 cache +platform. In power save mode, when clocks run on a lower frequency, the DMA +preparation may cost even more. As long as these slower preparations are run +in parallel with the transfer performance won't be affected. + +Details on measurements from IOZone and mmc_test +================================================ + +https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req + +MMC core API extension +====================== + +There is one new public function mmc_start_req(). +It starts a new MMC command request for a host. The function isn't +truly non-blocking. If there is on ongoing async request it waits +for completion of that request and starts the new one and returns. It +doesn't wait for the new request to complete. If there is no ongoing +request it starts the new request and returns immediately. + +MMC host extensions +=================== + +There are two optional hooks -- pre_req() and post_req() -- that the host +driver may implement in order to move work to before and after the actual +mmc_request function is called. In the DMA case pre_req() may do +dma_map_sg() and prepare the DMA descriptor, and post_req runs +the dma_unmap_sg. + +Optimize for the first request +============================== + +The first request in a series of requests can't be prepared in parallel with +the previous transfer, since there is no previous request. +The argument is_first_req in pre_req() indicates that there is no previous +request. The host driver may optimize for this scenario to minimize +the performance loss. A way to optimize for this is to split the current +request in two chunks, prepare the first chunk and start the request, +and finally prepare the second chunk and start the transfer. + +Pseudocode to handle is_first_req scenario with minimal prepare overhead: +if (is_first_req && req->size > threshold) + /* start MMC transfer for the complete transfer size */ + mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); + + /* + * Begin to prepare DMA while cmd is being processed by MMC. + * The first chunk of the request should take the same time + * to prepare as the "MMC process command time". + * If prepare time exceeds MMC cmd time + * the transfer is delayed, guesstimate max 4k as first chunk size. + */ + prepare_1st_chunk_for_dma(req); + /* flush pending desc to the DMAC (dmaengine.h) */ + dma_issue_pending(req->dma_desc); + + prepare_2nd_chunk_for_dma(req); + /* + * The second issue_pending should be called before MMC runs out + * of the first chunk. If the MMC runs out of the first data chunk + * before this call, the transfer is delayed. + */ + dma_issue_pending(req->dma_desc); -- 1.7.4.1

13 years, 3 months

libjpeg-turbo-1.1.1 + linaro Performance

by Tom Gall

Hi All, I've taken some time to freshen up the libjpeg-turbo hosted at lp:libjpeg-turbo to be refreshed with the upstream 1.1.1 plus Mandeeps previous work. I thought as part of this effort I'd do some performance comparisons between this new cut of code and the much older non arm optimized libjpeg62. For this test, I selected 3 ppms and 3 jpegs of the same image. The images are all color and are of the sizes : 1920x1024, 406x357 and 7227x3847. I placed the images inside of a ramdisk as well as would run the cjpeg and djpeg applications with time. Both cjpeg and djpeg and statically linked. I believe the libjpeg62 and libjpeg-turbo code using the current 4.5.2 version of gcc using the 0706 panda hwpack and LEB. Note, while these numbers are interesting to a point, time is I believe the wrong tool to make this measurement. Instead the call to the jpeg code should have time stamps before and after the operation to get a better idea of the time used. Numbers: cjpeg (ppm to jpeg conversion default parms) image size libjpeg62 libjpeg-turbo improvement (positive numbers are better) 1920x1024 real 0m0.522s real 0m0.452s +0.070s user 0m0.438s user 0m0.352s +0.086s sys 0m0.055s sys 0m0.070s -0.015s 406x357 real 0m0.086s real 0m0.085s +0.001s user 0m0.047s user 0m0.047s 0s sys 0m0.008s sys 0m0.008s 0s 7227x3847 real 0m3.812s real 0m4.075s - 0.263s user 0m3.461s user 0m3.711s - 0.250s sys 0m0.305s sys 0m0.328s - 0.023s djpeg (jpeg to ppm conversion default parms) image size libjpeg62 libjpeg-turbo improvement 1920x1024 real 0m0.414s real 0m0.294s +0.120s user 0m0.273s user 0m0.156s +0.117s sys 0m0.109s sys 0m0.109s 0s 406x357 real 0m0.079s real 0m0.072s +0.007s user 0m0.023s user 0m0.016s +0.007s sys 0m0.023s sys 0m0.023s 0s 7227x3847 real 0m7.517s real 0m10.099s -2.582s user 0m2.047s user 0m1.242s +0.805s sys 0m0.813s sys 0m0.859s -0.046s Further work: There are some additional patches from Michael Edwards, those were not part of this measurement tho I will be picking his patches up. Better timestamp code instead of using time. -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox 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

[uboot PATCH] Add uboot "fdt_high" enviroment variable

by David A. Long

From: David A. Long <dave.long(a)linaro.org> Add a new "fdt_high" enviroment variable. This can be used to control (or prevent) the relocation of the flattened device tree on boot. It can be used to prevent relocation of the fdt into highmem. The variable behaves similarly to the existing "initrd_high" variable. Signed-off-by: David A. Long <dave.long(a)linaro.org> --- common/image.c | 45 +++++++++++++++++++++++++++++++++++---------- 1 files changed, 35 insertions(+), 10 deletions(-) diff --git a/common/image.c b/common/image.c index e542a57..d565f33 100644 --- a/common/image.c +++ b/common/image.c @@ -1234,8 +1234,10 @@ int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size) { void *fdt_blob = *of_flat_tree; void *of_start = 0; + char *fdt_high; ulong of_len = 0; int err; + int disable_relocation=0; /* nothing to do */ if (*of_size == 0) @@ -1249,7 +1251,24 @@ int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size) /* position on a 4K boundary before the alloc_current */ /* Pad the FDT by a specified amount */ of_len = *of_size + CONFIG_SYS_FDT_PAD; - of_start = (void *)(unsigned long)lmb_alloc_base(lmb, of_len, 0x1000, + + /* If fdt_high is set use it to select the relocation address */ + fdt_high = getenv("fdt_high"); + if(fdt_high) { + void *desired_addr = (void *) simple_strtoul(fdt_high, NULL, 16); + + if(((ulong) desired_addr) == ~0UL || desired_addr == NULL) { + /* Zero or all ones means use fdt in place */ + desired_addr = fdt_blob; + disable_relocation = 1; + } + of_start = (void *)(unsigned long)lmb_alloc_base(lmb, of_len, 0x1000, ((ulong) desired_addr) + of_len); + if(of_start != desired_addr) { + puts("Failed using fdt_high value for Device Tree"); + goto error; + } + } else + of_start = (void *)(unsigned long)lmb_alloc_base(lmb, of_len, 0x1000, getenv_bootm_mapsize() + getenv_bootm_low()); if (of_start == 0) { @@ -1257,18 +1276,24 @@ int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size) goto error; } - debug ("## device tree at %p ... %p (len=%ld [0x%lX])\n", - fdt_blob, fdt_blob + *of_size - 1, of_len, of_len); + if(disable_relocation) { + /* We assume there is space after the existing fdt to use for padding */ + fdt_set_totalsize(of_start, of_len); + printf(" Using Device Tree in place at %p, end %p\n", of_start, of_start+of_len-1); + } else { + debug ("## device tree at %p ... %p (len=%ld [0x%lX])\n", + fdt_blob, fdt_blob + *of_size - 1, of_len, of_len); - printf (" Loading Device Tree to %p, end %p ... ", - of_start, of_start + of_len - 1); + printf (" Loading Device Tree to %p, end %p ... ", + of_start, of_start + of_len - 1); - err = fdt_open_into (fdt_blob, of_start, of_len); - if (err != 0) { - fdt_error ("fdt move failed"); - goto error; + err = fdt_open_into (fdt_blob, of_start, of_len); + if (err != 0) { + fdt_error ("fdt move failed"); + goto error; + } + puts ("OK\n"); } - puts ("OK\n"); *of_flat_tree = of_start; *of_size = of_len;

13 years, 3 months

[ACTIVITY] Multimedia WG status report - wk27.2011 (20110704-20110708)

by Ilias Biris

Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-07-05 Current status report:https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyRe… Highlights: Issues/Changes: Mandeep Kumar is not contributing to Linaro work. A suitable replacement is sought after with the member company. As a plan-B Ilias has asked another member of the team to look after JPEG-turbo for 1107 release, providing the release and any necessary highlights to release management. This plan should be confirmed with Kurt once he is back from vac. Info has already been shared with the team member picking up jpeg-turbo As a result of this change sending the public plan review presentation to the TSC was postponed till Kurt has a new version of the plan. Public plan review: this is still planned to take place on 13 or 14 of July. Final date will be determined next week. The blueprints for the work now look to be mostly in shape. Still to cover - Userspace UMM - robclark needs to clarify whether any userspace API related to buffer sharing needs a separate blueprint or it can be as a set of work items in the existing memory management blueprints. - Jpeg optimization related to codec optimization - due to the change mentioned above this will need to be revised to identify how to meet the 1107 and beyond targets - As a result of the change the team will doublecheck other blueprints for any timeline adjustments needed -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 3 months

[NOTES] Kernel WG Weekly Status report 2011-07-08

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report for the kernel working group for the week ending 2011-07-08. == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-07-07 == Summary == * Updated linaro+android tree to linaro 11.06 final kernel * Worked on testing Android Alarm Timers integration with Posix Alarm Timers. * Rebased mmc non-blocking patchset v8 on to of mmc-next for 3.1. * Merged only one patch to linaro-2.6.39 fixing a bug in the MMC test module. * Started an experimental merge of Catalin Marinas' LPAE (ARM Large Physical Address Extension) patches with linux-linaro-2.6.39. Have a booting kernel on the ARM VExpress-CA15x4 model making use of physical memory beyond 4GB. 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

[Notes] Power Management WG Weekly Status report week 2011-07-08

by Mounir Bsaibes

Enclosed please find the link to the Meeting Minutes & Weekly Status report for the Power Management working group for the week ending 2011-07-08. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-07-06 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-07-07 == Summary == * Planning for 11.07 cycle, next milestone * Thermal Manager * Completed Runtime PM Adaptation of thermal sensor driver * Posted thermal sensor hwmod patches * Sched_mc * Follow cpu topology patch upstream * Test some config on sched_mc and powersaving on CA-9 * Prepare sched_mc discussion for August Linaro Connect * Update the non reg test for sched_mc * Powerdebug * Submitted tests for PM QA cpufreq * Modified script to conform to LAVA 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

[NOTES] Toolchain WG Weekly Status report 2011-07-08

by Mounir Bsaibes

Enclosed please find the links to the meetings minutes and Weekly Status report for the Toolchain working group for the week ending 2011-07-08. == Meetings minutes == https://wiki.linaro.org/WorkingGroups/Toolchain/Meetings/2011-07-04<https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-07-04> https://wiki.linaro.org/WorkingGroups/Toolchain/Meetings/2011-07-07<https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-07-07> == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-07-07 == Summary == * Continuing to run bechmarks to identify areas that can be improved * Revital is looking into SPEC quantum which has a very hot loop * The testsuite failures when running GDB as a cross debugger have been logged and started on * Looking into using libunwind remotely against Android as an example crash debugger * Various GCC patches including: * Widening multiply in the core * Widening multiply in the vectoriser * Half precision float support * Support for NEON shifts by immediate value * A good number of bug fixes 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

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev July 2011