linaro-dev February 2012

linaro-dev@lists.linaro.org

150 participants
147 discussions

[linux-pm][RFC PATCH] thermal: Add support to report cooling statistics achieved by cooling devices

by Amit Daniel Kachhap

Add a sysfs node code to report effective cooling of all cooling devices attached to each trip points of a thermal zone. The cooling data reported will be absolute if the higher temperature trip points are arranged first otherwise the cooling stats is the cumulative effect of the earlier invoked cooling handlers. The basic assumption is that cooling devices will bring down the temperature in a symmetric manner and those statistics can be stored back and used for further tuning of the system. Signed-off-by: Amit Daniel Kachhap <amit.kachhap(a)linaro.org> --- Documentation/thermal/sysfs-api.txt | 10 ++++ drivers/thermal/thermal_sys.c | 96 +++++++++++++++++++++++++++++++++++ include/linux/thermal.h | 8 +++ 3 files changed, 114 insertions(+), 0 deletions(-) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index b61e46f..1db9a9d 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -209,6 +209,13 @@ passive Valid values: 0 (disabled) or greater than 1000 RW, Optional +trip_stats + This attribute presents the effective cooling generated from all the + cooling devices attached to a trip point. The output is a pair of value + for each trip point. Each pair represents + (trip index, cooling temperature difference in millidegree Celsius) + RO, Optional + ***************************** * Cooling device attributes * ***************************** @@ -261,6 +268,9 @@ method, the sys I/F structure will be built like this: |---cdev0_trip_point: 1 /* cdev0 can be used for passive */ |---cdev1: --->/sys/class/thermal/cooling_device3 |---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/ + |---trip_stats 0 0 + 1 8000 /*trip 1 causes 8 degree Celsius drop*/ + 2 3000 /*trip 2 causes 3 degree Celsius drop*/ |cooling_device0: |---type: Processor diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index dd9a574..47e7b6e 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -92,6 +92,64 @@ static void release_idr(struct idr *idr, struct mutex *lock, int id) if (lock) mutex_unlock(lock); } +static void update_cooling_stats(struct thermal_zone_device *tz, long cur_temp) +{ + int count, max_index, cur_interval; + long trip_temp, max_temp = 0, cool_temp; + static int last_trip_level = -1; + + if (cur_temp >= tz->last_temperature) + return; + + /* find the trip according to last temperature */ + for (count = 0; count < tz->trips; count++) { + tz->ops->get_trip_temp(tz, count, &trip_temp); + if (tz->last_temperature >= trip_temp) { + if (max_temp < trip_temp) { + max_temp = trip_temp; + max_index = count; + } + } + } + + if (!max_temp) { + last_trip_level = -1; + return; + } + + cur_interval = tz->stat[max_index].interval_ptr; + cool_temp = tz->last_temperature - cur_temp; + + if (last_trip_level != max_index) { + if (++cur_interval == INTERVAL_HISTORY) + cur_interval = 0; + tz->stat[max_index].cool_temp[cur_interval] = cool_temp; + tz->stat[max_index].interval_ptr = cur_interval; + last_trip_level = max_index; + } else { + tz->stat[max_index].cool_temp[cur_interval] += cool_temp; + } +} + +static int calculate_cooling_temp_avg(struct thermal_zone_device *tz, int trip, + int *avg_cool) +{ + int result = 0, count = 0, used_data = 0; + + if (trip > THERMAL_MAX_TRIPS) + return -EINVAL; + + *avg_cool = 0; + for (count = 0; count < INTERVAL_HISTORY; count++) { + if (tz->stat[trip].cool_temp[count] > 0) { + *avg_cool += tz->stat[trip].cool_temp[count]; + used_data++; + } + } + if (used_data > 1) + *avg_cool = (*avg_cool)/used_data; + return result; +} /* sys I/F for thermal zone */ @@ -493,6 +551,26 @@ temp_crit_show(struct device *dev, struct device_attribute *attr, return sprintf(buf, "%ld\n", temperature); } +static ssize_t +thermal_cooling_trip_stats_show(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct thermal_zone_device *tz = to_thermal_zone(dev); + int avg_cool = 0, result, trip_index; + ssize_t len = 0; + + for (trip_index = 0; trip_index < tz->trips; trip_index++) { + result = calculate_cooling_temp_avg(tz, + trip_index, &avg_cool); + if (!result) + len += sprintf(buf + len, "%d %d\n", + trip_index, avg_cool); + } + return len; +} +static DEVICE_ATTR(trip_stats, 0444, + thermal_cooling_trip_stats_show, NULL); static struct thermal_hwmon_device * thermal_hwmon_lookup_by_type(const struct thermal_zone_device *tz) @@ -1049,6 +1127,8 @@ void thermal_zone_device_update(struct thermal_zone_device *tz) goto leave; } + update_cooling_stats(tz, temp); + for (count = 0; count < tz->trips; count++) { tz->ops->get_trip_type(tz, count, &trip_type); tz->ops->get_trip_temp(tz, count, &trip_temp); @@ -1181,6 +1261,13 @@ struct thermal_zone_device *thermal_zone_device_register(char *type, return ERR_PTR(result); } + /*Allocate variables for cooling stats*/ + tz->stat = devm_kzalloc(&tz->device, + sizeof(struct thermal_cooling_stats) * trips, + GFP_KERNEL); + if (!tz->stat) + goto unregister; + /* sys I/F */ if (type) { result = device_create_file(&tz->device, &dev_attr_type); @@ -1207,6 +1294,12 @@ struct thermal_zone_device *thermal_zone_device_register(char *type, passive = 1; } + if (trips > 0) { + result = device_create_file(&tz->device, &dev_attr_trip_stats); + if (result) + goto unregister; + } + if (!passive) result = device_create_file(&tz->device, &dev_attr_passive); @@ -1282,6 +1375,9 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz) for (count = 0; count < tz->trips; count++) TRIP_POINT_ATTR_REMOVE(&tz->device, count); + if (tz->trips > 0) + device_remove_file(&tz->device, &dev_attr_trip_stats); + thermal_remove_hwmon_sysfs(tz); release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id); idr_destroy(&tz->idr); diff --git a/include/linux/thermal.h b/include/linux/thermal.h index 47b4a27..47504c7 100644 --- a/include/linux/thermal.h +++ b/include/linux/thermal.h @@ -72,6 +72,13 @@ struct thermal_cooling_device_ops { #define THERMAL_TRIPS_NONE -1 #define THERMAL_MAX_TRIPS 12 #define THERMAL_NAME_LENGTH 20 +#define INTERVAL_HISTORY 12 + +struct thermal_cooling_stats { + int cool_temp[INTERVAL_HISTORY]; + int interval_ptr; +}; + struct thermal_cooling_device { int id; char type[THERMAL_NAME_LENGTH]; @@ -102,6 +109,7 @@ struct thermal_zone_device { struct list_head cooling_devices; struct idr idr; struct mutex lock; /* protect cooling devices list */ + struct thermal_cooling_stats *stat; struct list_head node; struct delayed_work poll_queue; }; -- 1.7.1

14 years, 1 month

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

by S, Venkatraman

On Sat, Feb 4, 2012 at 8:21 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. > > Signed-off-by: Rajendra Nayak <rnayak(a)ti.com> > --- > drivers/mmc/host/omap_hsmmc.c | 14 -------------- > 1 files changed, 0 insertions(+), 14 deletions(-) > > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 17e264b..97d3065 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -300,7 +300,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 +307,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); > @@ -358,10 +348,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) > -- Almost all usage of the id field is gone, except for a trivial debug print. Would be prudent to get rid of it entirely from struct omap_hsmmc_host.

14 years, 1 month

[PATCH] ux500 : decouple/recouple gic from the PRCMU

by Daniel Lezcano

This patch allows to decouple and recouple the gic from the PRCMU. This is needed to put the A9 core in retention mode with the cpuidle driver. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- drivers/mfd/db8500-prcmu.c | 42 ++++++++++++++++++++++++++++++++++++++ include/linux/mfd/db8500-prcmu.h | 2 + include/linux/mfd/dbx500-prcmu.h | 16 ++++++++++++++ 3 files changed, 60 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c index af8e0ef..c708431 100644 --- a/drivers/mfd/db8500-prcmu.c +++ b/drivers/mfd/db8500-prcmu.c @@ -528,6 +528,10 @@ static const char *hwacc_ret_regulator_name[NUM_HW_ACC] = { #define PRCMU_PLLDSI_LOCKP_LOCKED 0x3 +#define PRCMU_A9_MASK_REQ 0x00000328 +#define PRCMU_A9_MASK_REQ_MASK 0x00000001 +#define PRCMU_A9_MASK_ACK 0x0000032C + static struct { u8 project_number; u8 api_version; @@ -787,6 +791,44 @@ int db8500_prcmu_set_power_state(u8 state, bool keep_ulp_clk, bool keep_ap_pll) return 0; } +/* + * prcmu_gic_mask - apply the mask to the mask request + * register. This mask has the bits [1-31] reserved and + * the request applies to the bit 0 of this register. + */ +static inline void prcmu_gic_mask(u32 mask) +{ + u32 val = readl(_PRCMU_BASE + PRCMU_A9_MASK_REQ); + writel((val & ~PRCMU_A9_MASK_REQ_MASK) | mask, + _PRCMU_BASE + PRCMU_A9_MASK_REQ); +} + +/* + * db8500_prcmu_gic_disable - This function decouple the gic + * from the prcmu. + */ +void db8500_prcmu_gic_disable(void) +{ + prcmu_gic_mask(PRCMU_A9_MASK_REQ_MASK); + + /* Wait for gic mask register update */ + while (!(readl(_PRCMU_BASE + PRCMU_A9_MASK_REQ) & + PRCMU_A9_MASK_REQ_MASK)) + cpu_relax(); + + /* Wait a few cycles for the gic mask completion */ + udelay(1); +} + +/* + * db8500_prcmu_gic_enable - This function recouple the gic + * with the prcmu. + */ +void db8500_prcmu_gic_enable(void) +{ + prcmu_gic_mask(0); +} + /* This function should only be called while mb0_transfer.lock is held. */ static void config_wakeups(void) { diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h index 60d27f7..4a1032c 100644 --- a/include/linux/mfd/db8500-prcmu.h +++ b/include/linux/mfd/db8500-prcmu.h @@ -536,6 +536,8 @@ int prcmu_load_a9wdog(u8 id, u32 val); void db8500_prcmu_system_reset(u16 reset_code); int db8500_prcmu_set_power_state(u8 state, bool keep_ulp_clk, bool keep_ap_pll); +void db8500_prcmu_gic_disable(void); +void db8500_prcmu_gic_enable(void); void db8500_prcmu_enable_wakeups(u32 wakeups); int db8500_prcmu_set_epod(u16 epod_id, u8 epod_state); int db8500_prcmu_request_clock(u8 clock, bool enable); diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h index bac942f..a5fee69 100644 --- a/include/linux/mfd/dbx500-prcmu.h +++ b/include/linux/mfd/dbx500-prcmu.h @@ -237,6 +237,22 @@ static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk, keep_ap_pll); } +static inline void prcmu_gic_disable(void) +{ + if (machine_is_u5500()) + return; + else + return db8500_prcmu_gic_disable(); +} + +static inline void prcmu_gic_enable(void) +{ + if (machine_is_u5500()) + return; + else + return db8500_prcmu_gic_enable(); +} + static inline int prcmu_set_epod(u16 epod_id, u8 epod_state) { if (machine_is_u5500()) -- 1.7.5.4

14 years, 1 month

Re: FW: [PATCH 02/07] HWMON: DA9052/53 hwmon driver v1

by Ashish Jangam

On Tue, 2012-02-07 at 17:52 +0530, Ashish Jangam wrote: > Can you consider adding yourself or David as maintainer ? Not a must, > but no one else would really be able to support the driver. Thank for this, you can add my name. > > +Supported chips: > > + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs > > + Prefix: 'da9052' > > + Datasheet: Kindly visit www.dialog-semiconductor.com and request for the > > + official datasheet. > > + > Maybe, but that doesn't seem to be straightforward. The web site has no > search field, and I am not sure who to contact in the contact list. And > since there does not seem to be support in the US, I am not sure if one > is expected to contact someone in Europe or Taiwan or some other place. > > Maybe you can let me know how exactly to get the datasheets - I like to > keep those around for chips we are supporting. You need to request for DA9052/53 datasheet from www.dialog-semiconductor.com/DA9053.php > > > +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, toffset, result; > > + > > + 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; > > + > > + if ((tjunc - toffset) == 0) > > + result = 0; > > + else > > + /* Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 */ > > + result = 1708 * (tjunc - toffset) - 108800; > > + > > Hmm. > tjunc = 1, toffset = 2: > return 1708 * (-1) - 108800 = -108800 - 1708 = -110508 > tjunc = 2, toffset = 2: > return 0 > tjunc = 3, toffset = 2: > return 1780 * 1 - 108800 = -108800 + 1708 = -107092 > > I am not saying this is wrong, not having access to the data sheet, but > it is a bit odd. Why is the 0-difference case handled differently, and > why does it return 0 and not, say, -108800 ? > > If tjunc - toffset < 0 is invalid (no idea if it is, of course), it > might make sense to detect that condition. toffset is the trim value used for improving the calculated temperature accuracy so considering this tjunc - toffset <=0 seems to be not applicable cases. I will correct this along with your other comments and will re-submit the patch.

14 years, 1 month

[PATCH] sched: move CONFIG_IRQ_TIME_ACCOUNTING to common code

by Dmitry Antipov

Since CONFIG_IRQ_TIME_ACCOUNTING is architecture-agnostic, move it from x86 area to common code. Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org> --- arch/x86/Kconfig | 11 ----------- lib/Kconfig.debug | 11 +++++++++++ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5bed94e..4759676 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -805,17 +805,6 @@ config SCHED_MC making when dealing with multi-core CPU chips at a cost of slightly increased overhead in some places. If unsure say N here. -config IRQ_TIME_ACCOUNTING - bool "Fine granularity task level IRQ time accounting" - default n - ---help--- - Select this option to enable fine granularity task irq time - accounting. This is done by reading a timestamp on each - transitions between softirq and hardirq state, so there can be a - small performance impact. - - If in doubt, say N here. - source "kernel/Kconfig.preempt" config X86_UP_APIC diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 8745ac7..d6d7afc 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -299,6 +299,17 @@ config SCHEDSTATS application, you can say N to avoid the very slight overhead this adds. +config IRQ_TIME_ACCOUNTING + bool "Fine granularity task level IRQ time accounting" + default n + ---help--- + Select this option to enable fine granularity task irq time + accounting. This is done by reading a timestamp on each + transitions between softirq and hardirq state, so there can be a + small performance impact. + + If in doubt, say N here. + config TIMER_STATS bool "Collect kernel timers statistics" depends on DEBUG_KERNEL && PROC_FS -- 1.7.7.6

14 years, 1 month

Continued Snowball Audio Session

by Tom Gall

If you were at the Snowball Audio session today (or wanted to be but were not able to make it) by popular demand a "part 2" session has been scheduled for Tuesday February 7th at 11:00 am in the Blue room. See you there! -- 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

14 years, 1 month

[PATCH 02/07] HWMON: DA9052/53 hwmon driver v1

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> --- Documentation/hwmon/da9052 | 59 +++++++ drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/da9052-hwmon.c | 343 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 413 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..3035bae --- /dev/null +++ b/Documentation/hwmon/da9052 @@ -0,0 +1,59 @@ +Supported chips: + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs + Prefix: 'da9052' + Datasheet: Kindly visit www.dialog-semiconductor.com 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 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..a35d914 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 HWMON" + 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..d83f988 --- /dev/null +++ b/drivers/hwmon/da9052-hwmon.c @@ -0,0 +1,343 @@ +/* + * 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", +}; + +static inline int volt_reg_to_mV(int value) +{ + return ((value * 1000) / 512) + 2500; +} + +static inline int input_volt_to_mV(int value) +{ + return (value * 2500) / 1023; +} + +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); + vdd = volt_reg_to_mV(vdd); + return sprintf(buf, "%d\n", 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; + + ret = volt_reg_to_mV(ret); + return sprintf(buf, "%d\n", 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; + if (ret) + ret = input_volt_to_mV(ret); + + return sprintf(buf, "%d\n", 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, toffset, result; + + 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; + + if ((tjunc - toffset) == 0) + result = 0; + else + /* Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 */ + result = 1708 * (tjunc - toffset) - 108800; + + return sprintf(buf, "%d\n", result); +} + +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", 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(temp1_input, S_IRUGO, da9052_read_tbat, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, + DA9052_ADC_TBAT); +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, da9052_read_tjunc, NULL, + DA9052_ADC_TJUNC); +static SENSOR_DEVICE_ATTR(temp2_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_temp1_input.dev_attr.attr, + &sensor_dev_attr_temp1_label.dev_attr.attr, + &sensor_dev_attr_temp2_input.dev_attr.attr, + &sensor_dev_attr_temp2_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: + devm_kfree(&pdev->dev, hwmon); + 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); + devm_kfree(&pdev->dev, hwmon); + + 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");

14 years, 1 month

Multimedia Work Group at Linaro Connect

by Tom Gall

http://connect.linaro.org/events/event/lcq1-12/#schedule The Linaro Multimedia Team for 1Q Linaro Connect has 3 main goals. 1) We'll be identifying further candidates for NEON focused optimization.2) We'll be syncing up with the landing teams to discuss the state of audio on the various boards, thinking about how we can be more effective, and planning our next efforts.3) We'll be working with the Graphics team on the next steps surrounding dmb_buf usage. In summary the sessions are: Codecs:Codec NEON optimization - possibilities and priorities Audio:Tiny AlsaLinaro speech recognitionPanda, Panda ES audio Snowball AudioOrigen Audioimx53 audio Unified Memory Manager:Evolution of the general dma-buf frameworkUMM - further enablement on member platforms I would anticipate we'll add a neon session so be on the lookout for that! Stop by and interact with the team, we're located in Salon 3 on the 2nd floor with the Graphics team. -- 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

14 years, 1 month

How to participate in the connect remotely

by Zygmunt Krynicki

Hi. I'm curious how/if remote participation is going to work during this connect. Unlike past events we will not have the advantage of the Canonical IS teams that made everything just work. This probably includes the microphones in each room, the IRC channels, the projectors and the magic wifi. Is there any general way to participate remotely during this event or should I just bug my friends to place a laptop on a chair and run google hangouts? Thanks ZK -- Zygmunt Krynicki Linaro Validation Team

14 years, 1 month

Developer Platform, Plans and Goals for Connect

by Ricardo Salveti

Hey, Additionally to the sessions we'll have over the week, here are another 2 important links for our group: - Plans and Goals for Linaro Connect Q1.12: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/Plans - Hacking Sessions: https://wiki.linaro.org/Platform/DevPlatform/Connect/Q1.12/HackingSessions If you're interested on having a 'hands-on' at any topic described at this wiki pages, please visit room Salon 4. We have all needed hardware there, from boards to monitors, so we can easily get on hacking. Thanks, -- Ricardo Salveti de Araujo

14 years, 1 month

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2012