linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Zach Pfeffer

All, Just a quick reminder. If you're trying to get anything delivered into an Android target for 11.07 you should have talked to me and we should have an integration BP tracking it. You should also be testing your stuff against the Android target you want to deliver on. Simply getting source into an Android build that isn't turned on is not considered landing. Things will need to be tested, documented and characterized against Android. We're doing continuous integration so code should be pushed early and often. Here's the current list of things we're going to land in 11.07: https://launchpad.net/linaro-android/+milestone/11.07 If you're not sure where to start with Android talk to me and we'll get you going. You don't even need a board (though it helps). Our tip build right now is on Panda and will be pointing to the 3.0 kernel soon. -Zach

13 years, 11 months

Problems re-using "repo manifest -r" manifests with repo

by Paul Sokolovsky

Hello, Here at Linaro, we pull components for Android builds from various sources, like AOSP upstream, our forks of AOSP components (to fix compatibility issues with gcc 4.5/4.6, etc.), bootloaders and kernels from SoC support teams, etc. All in all, that means that we don't have full control over those repositories for example to tag them. So, to achieve build reproducibility, we decided to use a feature that repo provides, exporting "release" manifest for a build using "repo manifest -r", which dumps manifest with SHA1 revision ids of components used for particular build. However, we found that such release manifests are not robust over time. If an upstream project uses rebase work model, then, even if a particular revision was tagged which ensures that this revision won't be garbage-collected if rebased later in main branch, the repo tool may not be able to fetch it. This happens because, unlike git clone, the repo tool limits what it fetches to refs/heads/*. So, if some revision is not reachable from one of branches (but still reachable from refs/tags/*), it will lead to an error like: error.GitError: boot/u-boot-linaro-stable update-ref: error: Trying to write ref refs/remotes/m/linaro_android_2.3.3 with nonexistant object 9736a9332fcfe5fef1361a6d91740e160ad04bd5 fatal: Cannot update the ref 'refs/remotes/m/linaro_android_2.3.3'. So, we would like to know if this can be considered a bug (it looks pretty much such for us, after all, we're just trying to feed up repo with what it generated, while 100% having valid revisions in the underlying repositories), and can be fixed. The patch would be pretty simple: diff --git a/project.py b/project.py index 9d67dea..31ee90f 100644 --- a/project.py +++ b/project.py @@ -1369,7 +1374,7 @@ class Project(object): else: ref_dir = None - cmd = ['fetch'] + cmd = ['fetch', '--tags'] # The --depth option only affects the initial fetch; after that we'll do # full fetches of changes. -- 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

13 years, 11 months

Usefulness of GCC's 64bit __sync_* ops on ARM

by Ken Werner

Hi, We've been thinking about adding support for the built-in functions for 64bit atomic memory access and I'd like to know if this is of any interest. Currently the main use of these functions seems to be to implement (SMP safe) locking mechanisms where the existent 32bit memory ops are sufficient. However, there might be code out there that implements a parallel algorithm using 64bit atomic memory operations. Currently the GCC ARM backend doesn't provide a pattern to inline 64bit __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The libgcc does not provide these symbols via the usual thin wrapper around the kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only. My understanding is that for ARMv7 the GCC backend could be enhanced to inline the __sync_* functions by using the LDREXD and STREXD instructions. But for ARMv5 we would still rely on a new kernel helper. Any ideas/thoughts are appreciated. [1] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#GCC [2] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#impl… Regards Ken

13 years, 11 months

[PATCH 0/2] ORIGEN Board Support

by Chander Kashyap

Adds support for ORIGEN board with MMC Booting. Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support MAINTAINERS | 1 + board/samsung/origen/Makefile | 46 ++ board/samsung/origen/lowlevel_init.S | 468 +++++++++++++++++++++ board/samsung/origen/mem_setup.S | 392 +++++++++++++++++ board/samsung/origen/origen.c | 103 +++++ boards.cfg | 1 + include/configs/origen.h | 167 ++++++++ mmc_spl/board/samsung/origen/Makefile | 105 +++++ mmc_spl/board/samsung/origen/mmc_boot.c | 75 ++++ mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 ++++++ mmc_spl/board/samsung/origen/u-boot.lds | 86 ++++ 11 files changed, 1583 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/origen.c create mode 100644 include/configs/origen.h create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds -- 1.7.4.1

13 years, 11 months

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

by Zygmunt Krynicki

Forwarding at it got bounced (odd?) ------ Wiadomość oryginalna ------ Temat: Re: ppas, version numbers, releases and validation.linaro.org Data: Mon, 11 Jul 2011 11:35:46 +0200 Nadawca: Zygmunt Krynicki <zygmunt.krynicki(a)linaro.org> Firma/Organizacja: Linaro Adresat: Michael Hudson-Doyle <michael.hudson(a)linaro.org> Kopia: linaro-dev(a)linaro.org, paul.larson(a)linaro.org W dniu 11.07.2011 06:34, Michael Hudson-Doyle pisze: > 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). Agreed > 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 :) I do bzr bd && bzr bd -S followed by some pbuilder commands. Look at .bzr-builder/ in each packaging branch. > 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. 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: 1) We need a new release, the pattern is always the same: ${UPSTREAM}-0ubuntu0~${PACKAGE}${PACKAGE_VERSION} Where PACKAGE is the marker (currently zyga) and PACKAGE_VERSION is reset to 0 each time UPSTREAM changes. 2) Our packages land in Ubuntu. The version becomes: ${UPSTREAM}-0ubuntu${PACKAGE_VERSION} Where PACKAGE_VERSION is >= 1 (this is important to differentiate from all of our internal releases 3) Our packages land in Debian. The version in Debian becomes: ${UPSTREAM}-${PACKAGE_VERSION} The version in Ubuntu becomes/changes to: ${UPSTREAM}-${PACKAGE_VERSION}ubuntu${UBUNTU_PACKAGE_VERSION} Where PACKAGE_VERSION is the one from Debian and UBUNTU_PACKAGE_VERSION is something Ubuntu developers can increment. > > 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. Agreed. I will look at this problem this week, hopefully I'll resurrect the package builder code. Thanks ZK

13 years, 11 months

better libjpeg-turbo 1.1.1 perf numbers

by Tom Gall

Hi All, I put some timestamp code into the compress and decompress testcases that I had posted about last friday for libjpeg-turbo. I have new and much better performance numbers as a result. In addition, I've put together a simple wiki page to capture various libjpeg-turbo kinds of things. https://wiki.linaro.org/TomGall/LibJpegTurbo >From the table there is an improvement in the libjpeg-turbo-1.1.1+patches from libjpeg62 of approx 30-40% in the decode case. In the encode case there are improvements from 6 to 17% however with larger images a regression is noted. -- 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, 11 months

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, 11 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, 11 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, 12 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, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev