linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Linaro Kernel December 2011 Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) is excited to announce the availability our December 2011 development snapshot: linux-linaro-3.1-2011.12-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.12/+download/linux-linaro-3.… The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.12-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.1.5 stable kernel - Inital thermal framework support (Amit Kacchap) - Updates to ARM perf support (Will Deacon) - Improvements to ARM OOM killer support (Kautuk Consul) A full change log against the 2011.11 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.12/+download/CHANGELOG-linux… High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

13 years, 10 months

perf fixes not present in Linaro kernel

by Will Deacon

Hi Nicolas, It seems as though some of my perf patches have ended up in the Linaro kernel source but the fixes that I've pushed during the -rc haven't made it: https://bugs.launchpad.net/linaro-landing-team-freescale/+bug/893653 https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/843628 Rather than me point each landing team at the patches, would you be able to cherry-pick the fixes from mainline please? They are: bce34d14 ("ARM: perf: initialise used_mask for fake PMU during validation") e5a21327 ("ARM: perf: check that we have a platform device when reserving PMU") 6bd05409 ("ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs") Hopefully that way all of the landing teams will receive the patches via the main Linaro kernel tree. Cheers, Will

13 years, 10 months

Jenkins LAVA hook

by Zach Pfeffer

Frans, Paul Sokolovsky has some details about an issue we're running into passing builds to LAVA from android-build with our new proprietary binaries? Paul would you tell Frans about it? -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 10 months

Re: "struct user" conflicts on arm

by Wookey

This subject came up on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00025.html And it seems like the sort of architectural issue linaro should take an interest in fixing to avoid making people's lives difficult when building on arm. Is it on anyone's list already? In short: A C app that defines a struct 'user' and uses wait.h or signal.h will find a clash with the system struct of the same name, which should only be needed for GDB (when built on/for arm). On other arches this is not pulled in by default so the problem doesn't arise. We can 1) Change every app in the world that defines a 'struct user' 2) Stop these headers getting brought in when not actually needed (it's a relatively recent change that brings it in) 3) Change the name in glibc/GDB to something less likely to clash disclaimer: I know nothing at all about this except what I just read in that thread. Please refer to the thread for details. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

13 years, 10 months

first rebuild of precise pangolin, including armhf

by Matthias Klose

This week, a kind of rebuild for precise pangolin in the disguise of the armhf bootstrap did end. The build did expose some ARM unspecific build failures; please use the information from the armhf build logs to address these build failures. Please use the ftbfs pages to gather more information: - http://qa.ubuntuwire.com/ftbfs/ (not yet showing armhf) This mostly shows failures introduced by syncs from Debian unstable (Debian didn't yet file bug reports after introducing the -Werror=format-security default). - http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html Shows armhf and armel build failures. Look at build failures which appear on armhf but not armel. These are likely build failures for other architectures as well. There are some generic issues found in more than one package: - default CFLAGS/CXXFLAGS include -Werror=format-security. Fixes are easy; don't stop fixing the first occurrence, but complete a local build. - Gnome pkgconfig files dropping -lm from Libs, and other packages not explicitly linking with -lm (resulting in symbols like "sqrt" and "pow" not found). - libreadline-dev dropping build dependency on libncurses-dev, and libncurses introducing a new libtinfo library. ARM (hf) specific issues include - compilers not yet built on armhf (gnat, fpc, ocamlopt), or not yet having the correct defaults (clang). - packaging mentioning armel only, but not armhf; usually needs fixes in both the control and rules files. http://people.canonical.com/~adconrad/universe-armel-armhf_differences might help with these although it includes all the packages build depending on gnat and fpc. - hard float issues, needing porting work. known ones are libreoffice, ocamlopt and fpc, but there will be more ... The armhf precise archive is installable with debootstrap(1) in a chroot on any armel Ubuntu/Linaro release. Thanks to Adam Conrad for driving the bootstrap, to Loic Minier for fixing ARM issues on the fly, to the Losa's for keeping the build farm alive, and many others. Matthias

13 years, 10 months

[ACTIVITY] Multimedia WG weekly report - wk49.2011 (2011120 - 20111209)

by Ilias Biris

Detailed dashboard: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-12-13 Highlights: - Moving on with the release for realvideo end-to-end audio testing (basic prototype), speex, UCM (initialize ucm testcase to make sure ucm4pa works properly, loaded pulseaudio patches) - Found a way to work around lava-test proxy issue: cma lava-test submitted to test the only one snowball in board farm - Started working with gstplayer (gstreamer playbin2 based) for xbmc (xorg on i.mx boards is really slow, xbmc package for the LEB is very slow as well) - Started working on the api differences post for tinyalsa vs alsa-lib - Continued pushing patches for omapdrm (dri2video work) for the 3.3 merge window Issues: - Bug #893402 is impeding progress in end-to-end audio testing (only a prototype is available for desktop - pandaboard is not functional). We're working on the bug - CMA lava-test is very long (around 2 hours) and there is only one snowball on test farm, so it will takes long to debug/fix it - Related to xbmc effort: there's SLOW xorg (no hw accel) on i.mx53 with linaro image and will probably be missing also for 11.12. Biggest problem is xbmc dvdplayer - a replacement for dvdplayer that uses gst demuxer and decoders would work much better. The work for xbmc is now moving to 12.01 with this gstreamer-related blueprint Risks -It is possible to delay the Huffman optimisations for LJT work planned for 11.12 to complete in 12.01 instead - It is possible to move Speex LAVA benchmarking to 12.01 - Since CMA lava-test is very long (around 2 hours) and there is only one snowball on test farm, the CMA testing blueprint could be put on hold. This is not a huge impediment - since we can already execute the CMA lava-test with local method -- 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, 10 months

[ACTIVITY] Graphics WG weekly report - wk49.2011 (20111205-20111209)

by Ilias Biris

Detailed dashboard: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last weekly meeting minutes https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-12-14 Highlights: - bug #855524 was fixed, so glproxy can now be enabled for glcompbench - glmark2: added live FPS counter on the screen (enabled via commandline option) - glcompbench: Fixed a bug in ShaderSource which caused a failure on pandaboard - dmabuf: incorporated v2 review comments, taking care now of all the outstanding comments - dmabuf - started setting up the work for a demo aimed at ELC - Updated the Mali user and kernel drivers for Linaro ICS - they were released to the LT - reportedly they work fine - Ongoing analysis of cpufreq to get hints on GPU power management Issues: - Unity/NUX/Compiz: we have the code with fixes from Frederic Plourde for unity, nux and compiz to resolve the framebuffer object issues (in short: compiz gained a system to manage FBOs and uses FBO to draw in before painting to the screen - useful for post-processing. Unfortunately Unity makes heavy use of FBOs via nux and the UnityFBO system itself). Ricardo Salveti has agreed to put together the packages needed for the release Questions/Issues - please point them out to me Best regards, -- 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, 10 months

git oddness

by Tom Gall

Hi All, I'm trying to push some code to my repo on git.linaro.org and it's like the repo is silently failing Note the following: tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git android:origin/1.2-beta-linaro-andoid Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 429 bytes, done. Total 3 (delta 2), reused 0 (delta 0) To ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git 746c51b..95ed21e android -> origin/1.2-beta-linaro-andoid tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status # On branch android # Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit. # nothing to commit (working directory clean) tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git android:origin/1.2-beta-linaro-andoid Everything up-to-date tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch * android master tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch -r origin/1.1.0-linaro origin/1.1.1-linaro origin/1.1.1-linaro-android origin/1.2-beta-linaro-andoid origin/HEAD -> origin/master origin/master git log does correctly show the commit on the local branch: commit 95ed21e84965f859da0792558742f9cbf9d4ac7a Author: Tom Gall <tom.gall(a)linaro.org> Date: Wed Dec 14 19:20:49 2011 -0600 Remove config.h since it was conflicting with other Android components. From cyang. ideas? suggestions? -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 10 months

[Patch 06/06] Regulator: DA9052/53 Regulator support v5

by Ashish Jangam

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> --- 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 4e919b2..7a61b17 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -178,6 +178,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 c75a522..503bac8 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -30,6 +30,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..47481f0 --- /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 LDOs 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"); -- 1.7.1

13 years, 10 months

low-cost EOMA-PCMCIA CPU Card initiative (allwinner cortex a8)

by Luke Kenneth Casson Leighton

folks, hi, apologies for the wide distribution of this message, reasons will become clear: please do subscribe to arm-netbooks(a)lists.phcomp.co.uk and respond there (subscription required) rather than to all these lists. the short version of the story is that Rhombus Tech (a CIC company - not a not-for-profit or a Ltd Company) is now taking preorder committments - pledges - to buy EOMA-PCMCIA-compliant CPU cards using a low-cost but feature-rich ARM Cortex A8 CPU called the Allwinner A10. http://http://rhombus-tech.net//allwinner_a10/orders/ some bullet-points: * this initiative is similar to the openpandora, the openmoko, ben nanonote etc. except that the lessons have been learned from these projects, to keep it very very simple, low-risk and modular, but still functional and useful (to Software Libre Developers) as a module. the goal is also different in that the plan is to leverage mass-volume pricing and opportunities, to the direct benefit of the Software (Libre) Community. more info on http://rhombus-tech.net main page. * the A10 has (at least) HDMI, SATA-II, 10/100 Ethernet, takes up to 1gb of 800mhz DDR3 RAM, has a superb 32-bit-wide 8-way concurrent DMA-driven NAND Flash interface, MALI 400MP 3D Graphics, does 2160p (2x 1080p) Video, has 4 SD 3.0 Ultra-High-Speed interfaces, 2x 24-pin RGB/TTL LCD interfaces, IDE (PATA)... i'm repeating what's on the rhombus tech web site so will stop here (link below) * the price of the allwinner CPU is so low in mass-volume ($USD 7) that in mass-volume (100k pricing) a PCB that is comparable to the raspberrypi would only be $USD 15 instead of $25, yet the A10 would be 3x faster processing speed (the rbpi's CPU is only a 700mhz ARM11 yet is more expensive). * the CPU card will be able to operate as a stand-alone (USB-OTG powered) computer, with HDMI output, boot from Micro-SD, and stereo headphones/mic, yet due to EOMA-PCMCIA compliance it will plug into a wide range of future devices. * unlike the beagleboard, origen, IMX53QSB etc. this is not a SoC-fabless-semiconductor-company-driven or a Linaro-driven initiative, it is a commercial initiative with an absolute top priority focus on GPL compliance and involving Software (Libre) Developers every step of the way, hence the reason for using a CIC not a Ltd Company. * GPL Kernel Source code has been obtained from allwinner: RHT has the full support of allwinner's Board of Directors, and the Reference Platform source code is available on alioth.debian.org. * as the primary focus of this initiative is, at this stage, to invite Software (Libre) Developers to be involved, it has not been widely announced. this is therefore the 1st reason why these lists are specifically being contacted. * as the CPU cards are designed to be in legacy PCMCIA form-factor, motherboards and devices such as tablets, laptops, plug computers, NAS boxes, IPTVs, are all possible, including embedded and other industrial purposes. the only other thing is that we are actively seeking "Admins" for the Rhombus Tech web site, from a wide range of different communities. the responsibilities are very small - they're a bit like those of slashdot meta-moderation. primarily we need people to be able to vet sponsorship for receipt of developer boards, using the profits raised by the CIC, for the direct strategic benefit of the Software (Libre) Community. this is similar in effect to the beagleboard sponsorship programme, but unlike the beagleboard sponsorship programme, if sufficient profits are raised by the CIC it will be possible for Admins to decide to donate boards taking up the entire years' remaining profits in one go, to worthwhile causes. clearly, to find such people it is necessary to reach an appropriate audience, hence the 2nd reason why this message is going specifically to ARM lists in each of the major gnu/linux distros. there are at present 4 people who have agreed to be Admins, including phil hands, alain williams, wookey and james vasile, each in "unofficial" capacities with no relation to any other duties or roles that they fulfil. ideally we could do with one or two more from each of the other gnu/linux distros. lastly: there *is* the possibility of adapting something like the beaglebone, which would, if the AM3357 was used, mean that the resultant hardware could potentially be FSF-Hardware-Endorsed: if this is something of interest to you please do speak up (on the arm-netbook(a)lists.phcomp.co.uk list) or likewise if you would prefer any other "Open Schematics" board such as IMX53QSB, pandaboard etc. to be adapted please do say so. ok i'll leave it at that. it's worth repeating - discussion please contact me either privately, directly, or subscribe to arm-netbook(a)lists.phcomp.co.uk, list instructions below. many thanks. links here: EOMA-PCMCIA spec: http://www.elinux.org/Embedded_Open_Modular_Architecture/PCMCIA allwinner page: http://http://rhombus-tech.net//allwinner_a10/ preorders page: http://http://rhombus-tech.net//allwinner_a10/orders/ accidental slashdot article: http://goo.gl/M7YQH rhombus-tech web site: http://rhombus-tech.net arm-netbooks: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook beaglebone idea: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001155.html am335x page: http://rhombus-tech.net/am335x

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev