linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

error handling and reporting in the dispatcher

by Michael Hudson-Doyle

I'm working on the dispatcher again, and as usual I'm getting a bit grumpy. Partly this is because the abstractions I added a couple of weeks ago aren't really working, but that's my problem. What I want to complain about is the error handling. I've always found the error handling in the dispatcher to be a little strange, so in this mail I'm going to try to set out the issue and maybe propose a solution. A lot of the confusion comes from the fact that there are many things that could be called an error in the dispatcher, and some overloading in the way we try to handle and report errors. Kinds of error that I can think of immediately: 1) Flat out bugs in the dispatcher 2) Errors in the job file (e.g. typoing an action name) 3) Failing tests 4) Tests that fail to even run 5) The board hanging at some point 6) Infrastructure failures, like l-m-c or deployment failing 7) Recoverable errors, e.g. where we want to be in the master image but might be in the linaro image Category 1 bugs we can't really do *too* much about -- if we have incorrect code, who's to say that the error handling code will be correct? -- but in general dispatcher bugs should IMO cause the dispatcher to exit with an exit code != 0 (we talked at the connect about having the scheduler display jobs that exited like this differently). Currently because we have lots of "except:"s all over the place, I think we risk swallowing genuine bugs (indeed, we had one of these for a while, where we said "self.in_master_shell()" instead of "self.client.in_master_shell()" but the AttributeError was caught). If we hit this sort of thing, I don't think we should try to continue to execute other actions and in particular I'm not too bothered if this kind of error does not result in a bundle being submitted to the dashboard. Category 2 -- errors in the job file -- we should try to detect as early as possible. Maybe we should even create the action objects and do a simple argument check before doing anything else? I think this sort of error should also result in an exit code != 0. To the extent that its reasonable, invalid job files should be rejected by the submit_job api call. As for bugs, I don't think we should try to continue to execute other actions and I'm not too bothered if this kind of error does not result in a bundle being submitted to the dashboard. Category 3 -- failing tests -- is not something the dispatcher itself should care about, at all. Category 4 -- tests that fail to run, I guess this includes things like lava-test hanging or crashing -- I think this should result in a failure in the magic 'lava' test run of the submitted bundle (and I think this is the case today). If this happens, I don't know if we should try to continue to execute other actions (apart from submit_results I guess). Category 5 -- things like the board hanging at some point -- I guess this depends a bit when this happens. If it's during deployment say, that's pretty bad -- certainly we shouldn't try to execute other non-reporting actions if this happens. Category 6 -- infrastructure failures -- seem to fall into the same kind of area as the previous 2: we should report a failure and stop executing any other actions. Category 7 -- recoverable failures -- are a bit different. We should log that they have happened and continue. After all this thinking and typing I think I've come to some conclusions: 1) There is a category of error where we should just stop. As far as I know, this isn't really handled today. 2) There is another category of error where we should report failure, but not execute any other actions. This makes me thing that having 'report results' as an action is a bit strange -- perhaps the dashboard and bundle stream should really be directly in the job, rather than an action? 3) I need to write another, probably equally long, email about dependencies between actions :-) Cheers, mwh

14 years, 10 months

[ACTIVITY] Android Platform Team 2011-10-31 to 2011-11-06

by Tony Mansson

Key Points for wider discussion =============================== * Toolchain build modified to generate both arm-eabi and arm-linux-androideabi toolchains Team Highlights =============================== * ALmost all Team members attended Connect * Progress on Androidizing Snowball GLK3.1 kernel * Workaround created for gdbserver crash on startup * All board kernels generates config.gz by default * A bot metrics script to determine the bot's contributions to gerrit done * Solution to LAVA test iMX53, Origen and Snowball on review * Progress on video recording bug * libpng 1.5.5 integration issues solved * Android builds on tool chain tip build * Progress on linphone on panda. Miscellaneous =============================== * New members Amit Pundir and Prashanth Srinivasan Issues =============================== * Slow progress on "Build the Non-Proprietary Igloo Android A Release with Linaro Tools" Blueprints =============================== https://launchpad.net/linaro-android/+milestone/11.11

14 years, 10 months

test files defined in src/com/android/mediaframeworktest/MediaNames.java

by yong qin

Hello, All Does anyone who know where to get the test files defined in file src/com/android/mediaframeworktest/MediaNames.java. or how to generate those files. like public static final String MP3CBR = "/sdcard/media_api/music/MP3_256kbps_2ch.mp3"; public static final String MP3VBR = "/sdcard/media_api/music/MP3_256kbps_2ch_VBR.mp3"; public static final String SHORTMP3 = "/sdcard/media_api/music/SHORTMP3.mp3"; public static final String MIDI = "/sdcard/media_api/music/ants.mid"; public static final String WMA9 = "/sdcard/media_api/music/WMA9.wma"; public static final String WMA10 = "/sdcard/media_api/music/WMA10.wma"; public static final String WAV = "/sdcard/media_api/music/rings_2ch.wav"; public static final String AMR = "/sdcard/media_api/music/test_amr_ietf.amr"; public static final String OGG = "/sdcard/media_api/music/Revelation.ogg"; public static final String SINE_200_1000 = "/sdcard/media_api/music/sine_200+1000Hz_44K_mo.wav"; public static String[] MP3FILES = { "/sdcard/media_api/music_perf/MP3/NIN_56kbps_32khz_stereo_VBR_MCA.MP3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_32khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_44.1khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_256kbps_44.1khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_256kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_192kbps_32khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/PD_256kbps_44.1khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/PD_256kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/WC_256kbps_44.1khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/WC_256kbps_48khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Apologize.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Because_Of_You.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Complicated.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Glamorous.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Im_With_You.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Smile.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Suddenly_I_See.mp3", "/sdcard/media_api/music_perf/regular_album_photo/When You Say Nothing At All.mp3", "/sdcard/media_api/music_perf/regular_album_photo/my_happy_ending.mp3"}; Thanks, Yongqin Liu

14 years, 10 months

[PATCH v2] pinctrl: hide subsystem from the populace

by Linus Walleij

From: Linus Walleij <linus.walleij(a)linaro.org> Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- ChangeLog v1->v2: - Removed some more pointless help text --- drivers/pinctrl/Kconfig | 22 +++++++--------------- 1 files changed, 7 insertions(+), 15 deletions(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index ef56644..e17e2f8 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -2,23 +2,17 @@ # PINCTRL infrastructure and drivers # -menuconfig PINCTRL - bool "PINCTRL Support" +config PINCTRL + bool depends on EXPERIMENTAL - help - This enables the PINCTRL subsystem for controlling pins - on chip packages, for example multiplexing pins on primarily - PGA and BGA packages for systems on chip. - - If unsure, say N. if PINCTRL +menu "Pin controllers" + depends on PINCTRL + config PINMUX bool "Support pinmux controllers" - help - Say Y here if you want the pincontrol subsystem to handle pin - multiplexing drivers. config DEBUG_PINCTRL bool "Debug PINCTRL calls" @@ -30,14 +24,12 @@ config PINMUX_SIRF bool "CSR SiRFprimaII pinmux driver" depends on ARCH_PRIMA2 select PINMUX - help - Say Y here to enable the SiRFprimaII pinmux driver config PINMUX_U300 bool "U300 pinmux driver" depends on ARCH_U300 select PINMUX - help - Say Y here to enable the U300 pinmux driver + +endmenu endif -- 1.7.3.2

14 years, 10 months

Neon Optimized Echo Cancellation

by Sangram PATNAIK

Hi, I'm trying to make a SIP stack run on a low-end processor (720 MIPS capable). Problem is the stack's EC is not neon-optimized & with a 256 ms EC tail, I'm exhausting the CPU. On one of the forums, I came across neon optimization trials for speex AEC by Linaro. Has there been a completed project? Or any other that can help me? Thank you for answering. Regards, Sangram **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***

14 years, 10 months

[PATCH] pinctrl: hide subsystem from the populace

by Linus Walleij

From: Linus Walleij <linus.walleij(a)linaro.org> Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/pinctrl/Kconfig | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index ef56644..e816f60 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -2,18 +2,15 @@ # PINCTRL infrastructure and drivers # -menuconfig PINCTRL - bool "PINCTRL Support" +config PINCTRL + bool depends on EXPERIMENTAL - help - This enables the PINCTRL subsystem for controlling pins - on chip packages, for example multiplexing pins on primarily - PGA and BGA packages for systems on chip. - - If unsure, say N. if PINCTRL +menu "Pin controllers" + depends on PINCTRL + config PINMUX bool "Support pinmux controllers" help @@ -40,4 +37,6 @@ config PINMUX_U300 help Say Y here to enable the U300 pinmux driver +endmenu + endif -- 1.7.3.2

14 years, 10 months

[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");

14 years, 10 months

Some more comments on CI loop interface

by Deepak Saxena

Hi Michael, I went to take a look at the kernel ci-loop page to see the build status of upstream builds and have a few new comments on the UIL 1) When there is a build failure, is it possible to have the build link go directly to the build results? It currently takes 3 clicks to get to the results from the main page and it may not be obvious to someone that the "consoleText" attachment is the correct link to use. 2) From the main ci-loop page, how do I get to a link for the RSS feed? Are the RSS feeds per-tree or per (tree + defconfig) combination? The later is preferred from the perspective of having upstream sub-arch maintainers who want to watch specific platforms. Thanks, ~Deepak

14 years, 10 months

Adding USB charge current property in the Linux Battery core

by ashishj3

Hi, For a better performance in USB charging operation, the DA9052/53 charging current can be configured in accordance with the USB host current delivering capacity (known through USB drivers negotiation). To implement this useful feature, a new writable property "USB charge current" needs to be added in the Linux battery core. Let me know your views on it. Regards, Ashish

14 years, 10 months

[ANN] New process for communicating Android Infrastructure issues and requests

by Paul Sokolovsky

Hello, Based on the discussions and decisions made at the Linaro Connect Q4.11, Infrastructure team is pleased to announce changes in the process of Linaro Android Infrastructure planning and maintenance. The main audience of the new process is Linaro Android Team, which is the primary stakeholder of the Android infrastructure, but it also applies to other groups and individuals in Linaro, as well as external contributors and community. The basic idea is to make Android infrastructure planning and management more sustainable, as well as improve the Infrastructure Team internal processes which will allow entire team to handle Android infrastructure tasks and improve cross-team work and knowledge sharing. The new process is as follows: 1. There's a new Linaro Android Infrastructure project at Launchpad, https://launchpad.net/linaro-android-infrastructure/ , which is intended to be a central facade for Android infrastructure development and maintenance. 2. The bugtracker in that project, https://bugs.launchpad.net/linaro-android-infrastructure is intended as a single contact point to report Android infrastructure issues, so please bookmark it and keep it handy. This ticket queue replaces all older communication means, like direct email, IRC pings, etc. (that doesn't mean they can't be used, it means that any issue should be reported as a ticket nonetheless). The bugtracker is indeed conceived to be a single point of contact, and if a ticket requires recursing to Linaro IS team, that will be handled by Infrastructure team itself. Using the "bug also affects project" Launchpad feature, tickets can be easily cross-posted to other projects which are affected. 3. The blueprints area in that project, https://blueprints.launchpad.net/linaro-android-infrastructure is used to host all blueprints related to Android infrastructure. That may change in the future (i.e. they will be filed against individual projects), but so far it's good step forward from such bluprints being filed against linaro-android project, which caused scheduling and accounting issues for both Android and Infrastructure teams. 4. The usual rules of thumb are applied to blueprints and tickets: Blueprints represent work to develop new (sub)systems or add non-trivial functionality to existing systems. They can be filed at any time, but prioritized and scheduled for execution at the beginning of monthly milestones. Tickets represent issues reports and requests to make changes which only Infra team can do, other maintenance requests, and feature requests. Tickets which turn out to require substantial effort, may be converted to blueprints. 5. For the time being, the Infrastructure team commits to working on 1-2 Android infrastructure blueprints each milestone, with more time spent on maintenance (including documentation and testsuites) of existing systems. Following the process above will allow us to optimize and improve our workflow, and provide more resources to Android infrastructure work, if that proves to be required. Thanks, 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

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev