linaro-dev February 2012

linaro-dev@lists.linaro.org

150 participants
147 discussions

[ANN] Support for fetching build configs from git for Android Builds

by Paul Sokolovsky

Hello, As the result of implementation of https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/build-… , android-build.linaro.org now can indirectly fetch build config stored in a git repository. To achieve that, bootstrap config (as specified in android-build.linaro.org) should contain reference to config's repo/branch/file (configuration variables are modeled on the similar MANIFEST_* ones), e.g.: BUILD_CONFIG_REPO=git://git.linaro.org/people/pfalcon/android/linaro/build-… BUILD_CONFIG_BRANCH=master BUILD_CONFIG_FILENAME=panda-ics-gcc46-tilt-tracking-blob.conf http://android.git.linaro.org/gitweb?p=linaro/build-configs.git;a=summary was created to store configs for the official builds in the Gerrit tree. Sample job is available here: https://android-build.linaro.org/builds/~pfalcon/git-build-config/ (it uses personal repo as a test). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

12 years, 10 months

February 2012 Kernel Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) and the Linaro Platform Group are excited to announce the availability our February 2012 development snapshot: linux-linaro-3.3-rc3-2012.02-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. We are excited about our first -rc based kernel as we move to a new process that will provide early access to more bleeding edge features on member-supported LEBs. The source tarball is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/linux-linar… The kernel sources can also be accessed using git at: git://git.linaro.org/people/ynk/linux-linaro-tracking.git tag: linux-linaro-3.3-rc3-2012.02-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.3-rc3 - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG * thermal_cpu_cooling patch set from the power management WG * irq_domain patch set from Grant L. (cherry-picked from linux-next) * Fix for https://bugs.launchpad.net/bugs/918412 * Basic device tree board support for supported ARM boards (comes from linux-linaro-3.1) * sched: Ensure cpu_power periodic update (Vincent G.) * ARM: kprobes: work around build errors (Arnd B.) * usb: ehci: make HC see up-to-date qh/qtd descriptors ASAP (Ming L.) * Perf: Fallback to /bin/more if less is not found for perf pager (Avik S.) A full change log against the 3.3-rc3 release is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/CHANGELOG-l… High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

12 years, 10 months

Upstream Patch Attribution and Traceability Errors

by Joey STANFORD

Hi Everyone, I wanted to remind you about two important things to consider when writing your patch comments for Linaro. I've been seeing some occasional upstream patches lately which have problems with a) attributions in the comments and b) traceability. So please... 1) Use your Linaro email address if you have it and also include your member/partner company e.g. Joey Stanford <joey(a)linaro.org> for the Samsung Landing Team e.g. Joey Stanford <joey(a)linaro.org> assigned to Linaro from IBM e.g. Joey Stanford <joey(a)personaladdress.net> for Linaro Currently I see patches submitted as "Joey Stanford <joey(a)canonical.com>" with no reference to Linaro at all. This is a problem firstly because we aren't attributing the code fully and secondly it reduces the awareness in the Open Source community of the benefits Linaro brings to the table. 2) If your work is based upon a bug or blueprint in Launchpad, or any other system for that matter, please: a) Put these in the bzr/git revision log via commit comment. Most of you are doing this and it's great. If you aren't, please do this. b) Consider including that in the comments for traceability. e.g. Fix for audio stack failure on IMX.53 Launchpad Bug #123 e.g. Implement Graphics acceleration on Origen, Google Code Issue #123 Today we are aware of some of our members who are grep'ing patch comments, but not revision logs, to extract this information and are not finding the details of what the patch fixes. I realize this somewhat of an edge case but every bit helps for traceability. Thanks, Joey -- Joey STANFORD Engineering Program Manager Office: +1-303-800-6609 http://www.linaro.org/ Open source software for ARM SoCs

12 years, 10 months

trouble building linux-linaro-3.0-2011.08-0

by John Rigby

I'm having trouble building the Thumb2 kernel on, I actually believe this same code worked some time ago before a toolchain update. There are actually two problems described below. I get past the first with a config change but don't know how to fix the second one. Start with mx51_defconfig, it builds uImage fine: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mx51_defconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage Save the working .config to config1 $ cp .config config1 Edit .config and remove this line then run make oldconfig. $ CONFIG_THUMB2_KERNEL is not set $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig Answer y to THUMB2_KERNEL and THUMB2_AVOID_R_ARM_THM_JUMP11 Save new Thumb2 enabled config to config2 Here is the diff: $ diff -u config1 config2 --- config1 2011-08-21 14:50:23.014654705 -0600 +++ config2 2011-08-21 14:51:13.164654727 -0600 @@ -339,9 +339,10 @@ CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_HZ=100 -# CONFIG_THUMB2_KERNEL is not set +CONFIG_THUMB2_KERNEL=y +CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y +CONFIG_ARM_ASM_UNIFIED=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y @@ -1417,7 +1418,6 @@ # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set -CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set @@ -1429,7 +1429,6 @@ # CONFIG_SYSCTL_SYSCALL_CHECK is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_C_RECORDMCOUNT=y Attempt to build this: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage ... LD init/built-in.o LD .tmp_vmlinux1 arch/arm/kernel/built-in.o: In function `get_wchan': early_printk.c:(.text+0x1400): undefined reference to `unwind_frame' arch/arm/kernel/built-in.o: In function `walk_stackframe': early_printk.c:(.text+0x2832): undefined reference to `unwind_frame' make: *** [.tmp_vmlinux1] Error 1 Poke around a bit and it looks like setting ARM_UNWIND could make difference so try that. Edit .config the remove # CONFIG_ARM_UNWIND is not set then run make old config again. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig Call the result config3 $ cp .config config3 So here is the cumulative diff $ diff -u config1 config3 --- config1 2011-08-21 14:50:23.014654705 -0600 +++ config3 2011-08-21 14:54:29.584654811 -0600 @@ -339,9 +339,10 @@ CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_HZ=100 -# CONFIG_THUMB2_KERNEL is not set +CONFIG_THUMB2_KERNEL=y +CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y +CONFIG_ARM_ASM_UNIFIED=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y @@ -1417,7 +1418,6 @@ # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set -CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set @@ -1429,7 +1429,6 @@ # CONFIG_SYSCTL_SYSCALL_CHECK is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_C_RECORDMCOUNT=y @@ -1443,7 +1442,7 @@ # CONFIG_KGDB is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set -# CONFIG_ARM_UNWIND is not set +CONFIG_ARM_UNWIND=y # CONFIG_DEBUG_USER is not set CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y Try building again. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage ... LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map OBJCOPY arch/arm/boot/Image Kernel: arch/arm/boot/Image is ready AS arch/arm/boot/compressed/head.o arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2' make[2]: *** [arch/arm/boot/compressed/head.o] Error 1 make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 make: *** [uImage] Error 2 Here is my gcc version: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.1-5ubuntu2~ppa1) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And as version: GNU assembler (GNU Binutils for Ubuntu) 2.21.52.20110707 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `arm-linux-gnueabi'. Three configs attached: config1 -- original config from make mx51_defconfig config2 -- config after turning on thumb2 config3 -- config after setting ARM_UNWIND Any help would be appreciated. Thanks John

12 years, 10 months

Initial Linaro+Android kernel for 11.12 is available

by john stultz

Zach reminded me that this month is compressed, so a linaro+android kernel would be needed immediately for 11.12. As Andrey is just ramping up in taking over for the Linaro Android kernel maintenance, I wanted to just get a kernel out, using the older kernel workflow, so that we had something current for 11.12. Anyway. This is straight from Andy Green's linaro-androidization-tracking branch, with a few small build fixes added on that I found in my testing and the base android_*_defconfig files. You can find the tree here: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.2-agreen-rebase The current sha is tagged as: linux-linaro-3.2-2011.12-0-android-0 Known issues: There seems to be something in the androidization branch that is causing problems on beagle xm and origen. In my testing beagle xm kernel ends up hanging in mid-boot(after ~4 seconds). And the orgien board doesn't show anything past "Uncompressing Linux... done, booting the kernel". If I drop the androidization patches and go back to the v3.2-rc4 base, both kernels boot until the Android userland environment starts and falls over because the android features are missing. I mucked about for awhile on both of these tonight, but wasn't able to solve either of them, so I'd appreciate any help trying to narrow down what is wrong on Origen (beagle is apparently lower priority). Andy, one issue with the re-factored android patch tree: Its not very bisect-able. If I jump back to a topic branch, frequently there are missing dependencies that keep it from building. Any thoughts on how we can better chase down these sorts of issues? thanks -john

12 years, 10 months

Re: [PATCH v2 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply

by S, Venkatraman

On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak <rnayak(a)ti.com> wrote: > > MMC1 is not the only instance that can be used/wired for SD. > So remove this assumption from the driver. > > Now that all the mmc id based usage is removed, get rid > of all the DEVID defines and also the 'id' field from the > omap_hsmmc_host structure. > > Signed-off-by: Rajendra Nayak <rnayak(a)ti.com> > Tested-by: Venkatraman S <svenkatr(a)ti.com> > Tested-by: Balaji T K <balajitk(a)ti.com> For the whole series, Acked-by: Venkatraman S <svenkatr(a)ti.com> > --- > drivers/mmc/host/omap_hsmmc.c | 31 ++----------------------------- > 1 files changed, 2 insertions(+), 29 deletions(-) > > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 17e264b..e3eb9d4 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -106,17 +106,6 @@ > #define SOFTRESET (1 << 1) > #define RESETDONE (1 << 0) > > -/* > - * FIXME: Most likely all the data using these _DEVID defines should come > - * from the platform_data, or implemented in controller and slot specific > - * functions. > - */ > -#define OMAP_MMC1_DEVID 0 > -#define OMAP_MMC2_DEVID 1 > -#define OMAP_MMC3_DEVID 2 > -#define OMAP_MMC4_DEVID 3 > -#define OMAP_MMC5_DEVID 4 > - > #define MMC_AUTOSUSPEND_DELAY 100 > #define MMC_TIMEOUT_MS 20 > #define OMAP_MMC_MIN_CLOCK 400000 > @@ -164,7 +153,6 @@ struct omap_hsmmc_host { > void __iomem *base; > resource_size_t mapbase; > spinlock_t irq_lock; /* Prevent races with irq handler > */ > - unsigned int id; > unsigned int dma_len; > unsigned int dma_sg_idx; > unsigned char bus_mode; > @@ -300,7 +288,6 @@ static int omap_hsmmc_set_power(struct device *dev, > int slot, int power_on, > static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host) > { > struct regulator *reg; > - int ret = 0; > int ocr_value = 0; > > mmc_slot(host).set_power = omap_hsmmc_set_power; > @@ -308,15 +295,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > reg = regulator_get(host->dev, "vmmc"); > if (IS_ERR(reg)) { > dev_dbg(host->dev, "vmmc regulator missing\n"); > - /* > - * HACK: until fixed.c regulator is usable, > - * we don't require a main regulator > - * for MMC2 or MMC3 > - */ > - if (host->id == OMAP_MMC1_DEVID) { > - ret = PTR_ERR(reg); > - goto err; > - } > } else { > host->vcc = reg; > ocr_value = mmc_regulator_get_ocrmask(reg); > @@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > mmc_slot(host).ocr_mask = ocr_value; > } else { > if (!(mmc_slot(host).ocr_mask & ocr_value)) { > - pr_err("MMC%d ocrmask %x is not > supported\n", > - host->id, > mmc_slot(host).ocr_mask); > + pr_err("MMC ocrmask %x is not > supported\n", > + mmc_slot(host).ocr_mask); > mmc_slot(host).ocr_mask = 0; > return -EINVAL; > } > @@ -358,10 +336,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > } > > return 0; > - > -err: > - mmc_slot(host).set_power = NULL; > - return ret; > } > > static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host) > @@ -1791,7 +1765,6 @@ static int __init omap_hsmmc_probe(struct > platform_device *pdev) > host->dev->dma_mask = &pdata->dma_mask; > host->dma_ch = -1; > host->irq = irq; > - host->id = pdev->id; > host->slot_id = 0; > host->mapbase = res->start; > host->base = ioremap(host->mapbase, SZ_4K); > -- > 1.7.1 >

12 years, 10 months

Re: [PATCH] HWMON: DA9052/53 hwmon driver v2

by Ashish Jangam

On Tue, 2012-02-21 at 16:48 +0530, Ashish Jangam wrote: > On Fri, 2012-02-10 at 07:58 -0500, Ashish Jangam wrote: > > The DA9052 PMIC provides an Analogue to Digital Converter with 10 bits > > resolution and 10 channels. > > > > + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs > > + Prefix: 'da9052' > > + Datasheet: Kindly visit www.dialog-semiconductor.com/product_table.php > > + and request for the official datasheet. > > + > Not really. From practical experience, the datasheet is not available > except for Dialog Semiconductor customers - not even for me to review > the driver (and that appears to be independent of my employer's > relationship with Dialog Semiconductor). I think this should read "not > publicly available". It is a bit misleading to suggest that it would be > available if that is not the case. Agreed. > > > +static const char * const input_names[] = { > > + [DA9052_ADC_VDDOUT] = "VDDOUT", > > + [DA9052_ADC_ICH] = "CHARGING CURRENT", > > + [DA9052_ADC_TBAT] = "BATTERY TEMP", > > + [DA9052_ADC_VBAT] = "BATTERY VOLTAGE", > > + [DA9052_ADC_IN4] = "ADC IN4", > > + [DA9052_ADC_IN5] = "ADC IN5", > > + [DA9052_ADC_IN6] = "ADC IN6", > > + [DA9052_ADC_TJUNC] = "BATTERY JUNCTION TEMP", > > + [DA9052_ADC_VBBAT] = "BACK-UP BATTERY VOLTAGE", > > +}; > > + > Where are those defines, or, in other words, which repository/branch is > your patch based on ? I don't see it in the current mainline kernel. The incremental ADC patch to the da9052 mfd core takes care of all such issues. However that patch is still under review...hoping to get it thru soon.

12 years, 10 months

Replicating Linaro Images to more memory cards

by Sudhangathan B S

I'm using Gumstix Overo-Fire. I need to replicate my systems to deploy and test my setup. Right now I have one uSD memory card which is working fine, but when I copy the whole card using either the `tar cvpf` or dd commands, the image doesn't work on any other memory card. Below is the console message when it hangs. I have tried many memory cards. Looks like Linaro images store the memory card ID and search for them during the boot time, which will obviously fail on a different card. Is there any way I can make my Linaro Image memory card independent.... so that my replication becomes easy..?? These are the last lines from the console messages during the boot, with the replicated memory card. [ 6.605651] usbcore: registered new interface driver usbhid [ 6.617279] usbhid: USB HID core driver Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/17fb7403-3757-4533-b783-7be5436d9882 does not exist. ! --------------------------------- Sudhangathan BS Ph:(+91) 9731-905-205 ---------------------------------

12 years, 10 months

[PATCH] HWMON: DA9052/53 hwmon driver v2

by Ashish Jangam

The DA9052 PMIC provides an Analogue to Digital Converter with 10 bits resolution and 10 channels. This patch montiors the DA9052 PMIC's ADC channels mostly for battery parameters like battery temperature, junction temperature, battery current etc. This patch is functionally tested on Samsung SMDKV6410. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- Changes since v1 - Update documentation file for url - Modify the entry in Kconfig file - Correct reporting of junction temperature - Add conversion function for backup battery voltage - Change labels for temperatures in the device attributes to follow sensor index --- Documentation/hwmon/da9052 | 62 ++++++++ drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/da9052-hwmon.c | 344 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 417 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/da9052 create mode 100644 drivers/hwmon/da9052-hwmon.c diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052 new file mode 100644 index 0000000..7caa066 --- /dev/null +++ b/Documentation/hwmon/da9052 @@ -0,0 +1,62 @@ +Supported chips: + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs + Prefix: 'da9052' + Datasheet: Kindly visit www.dialog-semiconductor.com/product_table.php + and request for the official datasheet. + +Authors: David Dajun Chen <dchen(a)diasemi.com> + +Description +----------- + +The DA9052/53 provides an Analogue to Digital Converter (ADC) with 10 bits +resolution and track and hold circuitry combined with an analogue input +multiplexer. The analogue input multiplexer will allow conversion of up to 10 +different inputs. The track and hold circuit ensures stable input voltages at +the input of the ADC during the conversion. + +The ADC is used to measure the following inputs: +Channel 0: VDDOUT - measurement of the system voltage +Channel 1: ICH - internal battery charger current measurement +Channel 2: TBAT - output from the battery NTC +Channel 3: VBAT - measurement of the battery voltage +Channel 4: ADC_IN4 - high impedance input (0 - 2.5V) +Channel 5: ADC_IN5 - high impedance input (0 - 2.5V) +Channel 6: ADC_IN6 - high impedance input (0 - 2.5V) +Channel 7: XY - TSI interface to measure the X and Y voltage of the touch +screen resistive potentiometers +Channel 8: Internal Tjunc. - sense (internal temp. sensor) +Channel 9: VBBAT - measurement of the backup battery voltage + +By using sysfs attributes we can measure the system voltage VDDOUT, the battery +charging current ICH, battery temperature TBAT, battery junction temperature +TJUNC, battery voltage VBAT and the back up battery voltage VBBAT. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 10 bit ADC. + +The battery voltage is calculated as: + Milli volt = ((ADC value * 1000) / 512) + 2500 + +The backup battery voltage is calculated as: + Milli volt = (ADC value * 2500) / 512; + +The voltages on ADC channels 4, 5 and 6 are calculated as: + Milli volt = (ADC value * 2500) / 1023 + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 10 bit ADC. Junction and battery temperatures +are monitored by the ADC channels. + +The junction temperature is calculated: + Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 +The junction temperature attribute is supported by the driver. + +The battery temperature is calculated: + Degree Celcius = 1 / (t1 + 1/298)- 273 +where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255)) +Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively. diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 24d584a..42b5f1a 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -313,6 +313,16 @@ config SENSORS_DS1621 This driver can also be built as a module. If so, the module will be called ds1621. +config SENSORS_DA9052_ADC + tristate "Dialog DA9052/DA9053 ADC" + depends on PMIC_DA9052 + help + Say y here to support the ADC found on Dialog Semiconductor + DA9052-BC and DA9053-AA/Bx PMICs. + + This driver can also be built as module. If so, the module + will be called da9052-hwmon. + config SENSORS_EXYNOS4_TMU tristate "Temperature sensor on Samsung EXYNOS4" depends on ARCH_EXYNOS4 diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 8251ce8..5fe96e5 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -42,6 +42,7 @@ obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o +obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o obj-$(CONFIG_SENSORS_DME1737) += dme1737.o obj-$(CONFIG_SENSORS_DS620) += ds620.o obj-$(CONFIG_SENSORS_DS1621) += ds1621.o diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c new file mode 100644 index 0000000..9bef6ab --- /dev/null +++ b/drivers/hwmon/da9052-hwmon.c @@ -0,0 +1,344 @@ +/* + * HWMON Driver for Dialog DA9052 + * + * Copyright(c) 2012 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen <dchen(a)diasemi.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include <linux/delay.h> +#include <linux/err.h> +#include <linux/hwmon.h> +#include <linux/hwmon-sysfs.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/platform_device.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> + +struct da9052_hwmon { + struct da9052 *da9052; + struct device *class_device; + struct mutex hwmon_lock; +}; + +static const char * const input_names[] = { + [DA9052_ADC_VDDOUT] = "VDDOUT", + [DA9052_ADC_ICH] = "CHARGING CURRENT", + [DA9052_ADC_TBAT] = "BATTERY TEMP", + [DA9052_ADC_VBAT] = "BATTERY VOLTAGE", + [DA9052_ADC_IN4] = "ADC IN4", + [DA9052_ADC_IN5] = "ADC IN5", + [DA9052_ADC_IN6] = "ADC IN6", + [DA9052_ADC_TJUNC] = "BATTERY JUNCTION TEMP", + [DA9052_ADC_VBBAT] = "BACK-UP BATTERY VOLTAGE", +}; + +/* Conversion function for VDDOUT and VBAT */ +static inline int volt_reg_to_mV(int value) +{ + return ((value * 1000) / 512) + 2500; +} + +/* Conversion function for ADC channels 4, 5 and 6 */ +static inline int input_reg_to_mV(int value) +{ + return (value * 2500) / 1023; +} + +/* Conversion function for VBBAT */ +static inline int vbbat_reg_to_mV(int value) +{ + return (value * 2500) / 512; +} + +static int da9052_enable_vddout_channel(struct da9052 *da9052) +{ + int ret; + + ret = da9052_reg_read(da9052, DA9052_ADC_CONT_REG); + if (ret < 0) + return ret; + + ret |= DA9052_ADCCONT_AUTOVDDEN; + + return da9052_reg_write(da9052, DA9052_ADC_CONT_REG, ret); +} + +static int da9052_disable_vddout_channel(struct da9052 *da9052) +{ + int ret; + + ret = da9052_reg_read(da9052, DA9052_ADC_CONT_REG); + if (ret < 0) + return ret; + + ret &= ~DA9052_ADCCONT_AUTOVDDEN; + + return da9052_reg_write(da9052, DA9052_ADC_CONT_REG, ret); +} + +static ssize_t da9052_read_vddout(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret, vdd; + + mutex_lock(&hwmon->hwmon_lock); + + ret = da9052_enable_vddout_channel(hwmon->da9052); + if (ret < 0) + goto hwmon_err; + + vdd = da9052_reg_read(hwmon->da9052, DA9052_VDD_RES_REG); + if (vdd < 0) { + ret = vdd; + goto hwmon_err_release; + } + + ret = da9052_disable_vddout_channel(hwmon->da9052); + if (ret < 0) + goto hwmon_err; + + mutex_unlock(&hwmon->hwmon_lock); + return sprintf(buf, "%d\n", volt_reg_to_mV(vdd)); + +hwmon_err_release: + da9052_disable_vddout_channel(hwmon->da9052); +hwmon_err: + mutex_unlock(&hwmon->hwmon_lock); + return ret; +} + +static ssize_t da9052_read_ich(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_reg_read(hwmon->da9052, DA9052_ICHG_AV_REG); + if (ret < 0) + return ret; + + /* Equivalent to 3.9mA/bit in register ICHG_AV */ + return sprintf(buf, "%d\n", DIV_ROUND_CLOSEST(ret * 39, 10)); +} + +static ssize_t da9052_read_tbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + + return sprintf(buf, "%d\n", da9052_adc_read_temp(hwmon->da9052)); +} + +static ssize_t da9052_read_vbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, DA9052_ADC_VBAT); + if (ret < 0) + return ret; + + return sprintf(buf, "%d\n", volt_reg_to_mV(ret)); +} + +static ssize_t da9052_read_misc_channel(struct device *dev, + struct device_attribute *devattr, + char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int channel = to_sensor_dev_attr(devattr)->index; + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, channel); + if (ret < 0) + return ret; + + return sprintf(buf, "%d\n", input_reg_to_mV(ret)); +} + +static ssize_t da9052_read_tjunc(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int tjunc; + int toffset; + + tjunc = da9052_reg_read(hwmon->da9052, DA9052_TJUNC_RES_REG); + if (tjunc < 0) + return tjunc; + + toffset = da9052_reg_read(hwmon->da9052, DA9052_T_OFFSET_REG); + if (toffset < 0) + return toffset; + + /* + * Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 + * T_OFFSET is a trim value used to improve accuracy of the result + */ + return sprintf(buf, "%d\n", 1708 * (tjunc - toffset) - 108800); +} + +static ssize_t da9052_read_vbbat(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + struct da9052_hwmon *hwmon = dev_get_drvdata(dev); + int ret; + + ret = da9052_adc_manual_read(hwmon->da9052, DA9052_ADC_VBBAT); + if (ret < 0) + return ret; + + return sprintf(buf, "%d\n", vbbat_reg_to_mV(ret)); +} + +static ssize_t da9052_hwmon_show_name(struct device *dev, + struct device_attribute *devattr, + char *buf) +{ + return sprintf(buf, "da9052-hwmon\n"); +} + +static ssize_t show_label(struct device *dev, + struct device_attribute *devattr, char *buf) +{ + return sprintf(buf, "%s\n", + input_names[to_sensor_dev_attr(devattr)->index]); +} + +static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, da9052_read_vddout, NULL, + DA9052_ADC_VDDOUT); +static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VDDOUT); +static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, da9052_read_vbat, NULL, + DA9052_ADC_VBAT); +static SENSOR_DEVICE_ATTR(in3_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VBAT); +static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN4); +static SENSOR_DEVICE_ATTR(in4_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN4); +static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN5); +static SENSOR_DEVICE_ATTR(in5_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN5); +static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, da9052_read_misc_channel, NULL, + DA9052_ADC_IN6); +static SENSOR_DEVICE_ATTR(in6_label, S_IRUGO, show_label, NULL, + DA9052_ADC_IN6); +static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, da9052_read_vbbat, NULL, + DA9052_ADC_VBBAT); +static SENSOR_DEVICE_ATTR(in9_label, S_IRUGO, show_label, NULL, + DA9052_ADC_VBBAT); + +static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, da9052_read_ich, NULL, + DA9052_ADC_ICH); +static SENSOR_DEVICE_ATTR(curr1_label, S_IRUGO, show_label, NULL, + DA9052_ADC_ICH); + +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, da9052_read_tbat, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp2_label, S_IRUGO, show_label, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp8_input, S_IRUGO, da9052_read_tjunc, NULL, + DA9052_ADC_TJUNC); +static SENSOR_DEVICE_ATTR(temp8_label, S_IRUGO, show_label, NULL, + DA9052_ADC_TJUNC); + +static DEVICE_ATTR(name, S_IRUGO, da9052_hwmon_show_name, NULL); + +static struct attribute *da9052_attr[] = { + &dev_attr_name.attr, + &sensor_dev_attr_in0_input.dev_attr.attr, + &sensor_dev_attr_in0_label.dev_attr.attr, + &sensor_dev_attr_in3_input.dev_attr.attr, + &sensor_dev_attr_in3_label.dev_attr.attr, + &sensor_dev_attr_in4_input.dev_attr.attr, + &sensor_dev_attr_in4_label.dev_attr.attr, + &sensor_dev_attr_in5_input.dev_attr.attr, + &sensor_dev_attr_in5_label.dev_attr.attr, + &sensor_dev_attr_in6_input.dev_attr.attr, + &sensor_dev_attr_in6_label.dev_attr.attr, + &sensor_dev_attr_in9_input.dev_attr.attr, + &sensor_dev_attr_in9_label.dev_attr.attr, + &sensor_dev_attr_curr1_input.dev_attr.attr, + &sensor_dev_attr_curr1_label.dev_attr.attr, + &sensor_dev_attr_temp2_input.dev_attr.attr, + &sensor_dev_attr_temp2_label.dev_attr.attr, + &sensor_dev_attr_temp8_input.dev_attr.attr, + &sensor_dev_attr_temp8_label.dev_attr.attr, + NULL +}; + +static const struct attribute_group da9052_attr_group = {.attrs = da9052_attr}; + +static int __init da9052_hwmon_probe(struct platform_device *pdev) +{ + struct da9052_hwmon *hwmon; + int ret; + + hwmon = devm_kzalloc(&pdev->dev, sizeof(struct da9052_hwmon), + GFP_KERNEL); + if (!hwmon) + return -ENOMEM; + + mutex_init(&hwmon->hwmon_lock); + hwmon->da9052 = dev_get_drvdata(pdev->dev.parent); + + platform_set_drvdata(pdev, hwmon); + + ret = sysfs_create_group(&pdev->dev.kobj, &da9052_attr_group); + if (ret) + goto err_mem; + + hwmon->class_device = hwmon_device_register(&pdev->dev); + if (IS_ERR(hwmon->class_device)) { + ret = PTR_ERR(hwmon->class_device); + goto err_sysfs; + } + + return 0; + +err_sysfs: + sysfs_remove_group(&pdev->dev.kobj, &da9052_attr_group); +err_mem: + return ret; +} + +static int __devexit da9052_hwmon_remove(struct platform_device *pdev) +{ + struct da9052_hwmon *hwmon = platform_get_drvdata(pdev); + + hwmon_device_unregister(hwmon->class_device); + sysfs_remove_group(&pdev->dev.kobj, &da9052_attr_group); + + return 0; +} + +static struct platform_driver da9052_hwmon_driver = { + .probe = da9052_hwmon_probe, + .remove = __devexit_p(da9052_hwmon_remove), + .driver = { + .name = "da9052-hwmon", + .owner = THIS_MODULE, + }, +}; + +module_platform_driver(da9052_hwmon_driver); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("DA9052 HWMON driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-hwmon");

12 years, 10 months

Query: Multiple Mappings to Mem and ARMV6+

by viresh kumar

Hi Guys, Sorry for starting the long old thread again, but i have to start it as i was a bit confused. :( We know that we can't have multiple mappings with different attributes to the same physical memory on ARMv6+ machines due to speculative prefetch. So, we have following kind of mappings in kernel now (please correct me if i am wrong): - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable - ioremap() - blocked on Low Mem, so that we don't create Device type mapping to same mem - dma_alloc_coherent() and others: - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem (i.e. Non cacheable - Non Bufferable) - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable - Bufferable mapping - Maybe some other too... I have a doubt with the last mapping mentioned above. We have two mappings possibly to the same physical memory, with different attributes: One is Cacheable and other one is not. Is this allowed by ARM? Because the patch in which Russell blocked ioremap on Low Mem, he clearly mentioned that these attributes are also important and they should be same. Sorry if i am missing something :) -- viresh

12 years, 10 months

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2012