linaro-dev June 2011

linaro-dev@lists.linaro.org

149 participants
196 discussions

by David Long

Can someone explain why uboot copies the initrd and device tree data to higher memory when we boot panda with a dtb? I'm assuming there's a reason, but it seems a problematic thing to do (potentially even without >3/4GB SDRAM present). -dl

14 years

[PATCH] regulator: MAX8997: Fix for divide by zero error

by Tushar Behera

Currently, ramp_delay variable is used uninitialzed in max8997_set_voltage_ldobuck which gets called through regulator_register calls. To fix the problem, in max8997_pmic_probe, ramp_delay initialization code is moved before calls to regulator_register. Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: MyungJoo Ham <myungjoo.ham(a)samsung.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Samuel Ortiz <sameo(a)linux.intel.com> Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- drivers/regulator/max8997.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/max8997.c b/drivers/regulator/max8997.c index 10d5a1d..0fc7b8c 100644 --- a/drivers/regulator/max8997.c +++ b/drivers/regulator/max8997.c @@ -1124,6 +1124,10 @@ static __devinit int max8997_pmic_probe(struct platform_device *pdev) 0x3f); } + /* Misc Settings */ + max8997->ramp_delay = 10; /* set 10mV/us, which is the default */ + max8997_write_reg(i2c, MAX8997_REG_BUCKRAMP, (0xf << 4) | 0x9); + for (i = 0; i < pdata->num_regulators; i++) { const struct voltage_map_desc *desc; int id = pdata->regulators[i].id; @@ -1148,10 +1152,6 @@ static __devinit int max8997_pmic_probe(struct platform_device *pdev) } } - /* Misc Settings */ - max8997->ramp_delay = 10; /* set 10mV/us, which is the default */ - max8997_write_reg(i2c, MAX8997_REG_BUCKRAMP, (0xf << 4) | 0x9); - return 0; err: for (i = 0; i < max8997->num_regulators; i++) -- 1.7.4.1

14 years

Pandaboard is dumb after reset if USB OTG cable attached to the host

by Paul Sokolovsky

Hello, Month ago, during 11.05 release testing, we had a case when Pandaboard didn't boot with one particular build and one particular card, while worked well with with other combinations. During this test cycle, I hit similar conditions, which I however was able to trace to the following: if at the moment of reset/boot, there's a cable connected from Panda USB OTG (small) connector to host, it won't boot from SD. The D2 LED will light for about a second, then both will be off. Nothing is output on serial. As soon as you unplug cable from the host, all boots again. I'm not sure if this is a known condition, but guessed I'd share it. -- Best Regards, Paul

14 years

[PATCH v8 00/12] use nonblock mmc requests to minimize latency

by Per Forlin

How significant is the cache maintenance over head? It depends, the eMMC are much faster now compared to a few years ago and cache maintenance cost more due to multiple cache levels and speculative cache pre-fetch. In relation the cost for handling the caches have increased and is now a bottle neck dealing with fast eMMC together with DMA. The intention for introducing non-blocking mmc requests is to minimize the time between a mmc request ends and another mmc request starts. In the current implementation the MMC controller is idle when dma_map_sg and dma_unmap_sg is processing. Introducing non-blocking mmc request makes it possible to prepare the caches for next job in parallel to an active mmc request. This is done by making the issue_rw_rq() non-blocking. The increase in throughput is proportional to the time it takes to prepare (major part of preparations is dma_map_sg and dma_unmap_sg) a request and how fast the memory is. The faster the MMC/SD is the more significant the prepare request time becomes. Measurements on U5500 and Panda on eMMC and SD shows significant performance gain for large reads when running DMA mode. In the PIO case the performance is unchanged. There are two optional hooks pre_req() and post_req() that the host driver may implement in order to move work to before and after the actual mmc_request function is called. In the DMA case pre_req() may do dma_map_sg() and prepare the dma descriptor and post_req runs the dma_unmap_sg. Details on measurements from IOZone and mmc_test: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req Changes since v7: * rebase on mmc-next, on top of Russell's updated error handling. * Clarify description of mmc_start_req() * Resolve compile without CONFIG_DMA_ENIGNE issue for mmci * Add mmc test to measure how performance is affected by sg length * Add missing wait_for_busy in mmc_test non-blocking test. This call got lost in v4 of this patchset when refactoring mmc_start_req. * Add sub-prefix (core block queue) to relevant patches. Per Forlin (12): mmc: core: add non-blocking mmc request function omap_hsmmc: add support for pre_req and post_req mmci: implement pre_req() and post_req() mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for non-blocking transfers mmc: mmc_test: test to measure how sg_len affect performance mmc: block: add member in mmc queue struct to hold request data mmc: block: add a block request prepare function mmc: block: move error code in issue_rw_rq to a separate function. mmc: queue: add a second mmc queue request member mmc: core: add random fault injection mmc: block: add handling for two parallel block requests in issue_rw_rq drivers/mmc/card/block.c | 505 ++++++++++++++++++++++++----------------- drivers/mmc/card/mmc_test.c | 491 ++++++++++++++++++++++++++++++++++++++-- drivers/mmc/card/queue.c | 184 ++++++++++------ drivers/mmc/card/queue.h | 33 ++- drivers/mmc/core/core.c | 167 +++++++++++++- drivers/mmc/core/debugfs.c | 5 + drivers/mmc/host/mmci.c | 147 +++++++++++- drivers/mmc/host/mmci.h | 8 + drivers/mmc/host/omap_hsmmc.c | 87 +++++++- include/linux/mmc/core.h | 6 +- include/linux/mmc/host.h | 24 ++ lib/Kconfig.debug | 11 + 12 files changed, 1345 insertions(+), 323 deletions(-) -- 1.7.4.1

14 years

[PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency

by Per Forlin

How significant is the cache maintenance over head? It depends, the eMMC are much faster now compared to a few years ago and cache maintenance cost more due to multiple cache levels and speculative cache pre-fetch. In relation the cost for handling the caches have increased and is now a bottle neck dealing with fast eMMC together with DMA. The intention for introducing non-blocking mmc requests is to minimize the time between a mmc request ends and another mmc request starts. In the current implementation the MMC controller is idle when dma_map_sg and dma_unmap_sg is processing. Introducing non-blocking mmc request makes it possible to prepare the caches for next job in parallel to an active mmc request. This is done by making the issue_rw_rq() non-blocking. The increase in throughput is proportional to the time it takes to prepare (major part of preparations is dma_map_sg and dma_unmap_sg) a request and how fast the memory is. The faster the MMC/SD is the more significant the prepare request time becomes. Measurements on U5500 and Panda on eMMC and SD shows significant performance gain for large reads when running DMA mode. In the PIO case the performance is unchanged. There are two optional hooks pre_req() and post_req() that the host driver may implement in order to move work to before and after the actual mmc_request function is called. In the DMA case pre_req() may do dma_map_sg() and prepare the dma descriptor and post_req runs the dma_unmap_sg. Details on measurements from IOZone and mmc_test: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req Changes since v5: * Fix spelling mistakes, replace "none blocking" with non-blocking. * excluded patch "omap_hsmmc: use original sg_len..." since it is being merged separately. Per Forlin (11): mmc: add non-blocking mmc request function omap_hsmmc: add support for pre_req and post_req mmci: implement pre_req() and post_req() mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for non-blocking transfers mmc: add member in mmc queue struct to hold request data mmc: add a block request prepare function mmc: move error code in mmc_block_issue_rw_rq to a separate function. mmc: add a second mmc queue request member mmc: test: add random fault injection in core.c mmc: add handling for two parallel block requests in issue_rw_rq drivers/mmc/card/block.c | 534 ++++++++++++++++++++++++----------------- drivers/mmc/card/mmc_test.c | 361 +++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 184 +++++++++----- drivers/mmc/card/queue.h | 33 ++- drivers/mmc/core/core.c | 165 ++++++++++++- drivers/mmc/core/debugfs.c | 5 + drivers/mmc/host/mmci.c | 146 ++++++++++- drivers/mmc/host/mmci.h | 8 + drivers/mmc/host/omap_hsmmc.c | 87 +++++++- include/linux/mmc/core.h | 6 +- include/linux/mmc/host.h | 24 ++ lib/Kconfig.debug | 11 + 12 files changed, 1235 insertions(+), 329 deletions(-) -- 1.7.4.1

14 years

[RFC pm-qa 0/2] tests for cpufreq

by Daniel Lezcano

These tests are used to test the cpufreq driver on ARM architecture. As the cpufreq is not yet complete, the test suite is based on the cpufreq sysfs API exported on intel architecture, assuming it is consistent across architecture. The different tests are described at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts Each test's header contains an URL to the anchor related item of this web page describing the script. Daniel Lezcano (2): cpufreq: add a test set for cpufreq cpufreq: check the frequency affect the performances Makefile | 6 ++ cpufreq/test_01.sh | 43 ++++++++++ cpufreq/test_02.sh | 43 ++++++++++ cpufreq/test_03.sh | 64 ++++++++++++++ cpufreq/test_04.sh | 85 +++++++++++++++++++ cpufreq/test_05.sh | 145 ++++++++++++++++++++++++++++++++ cpufreq/test_06.sh | 236 ++++++++++++++++++++++++++++++++++++++++++++++++++++ utils/Makefile | 11 +++ utils/cpucycle.c | 102 ++++++++++++++++++++++ utils/nanosleep.c | 45 ++++++++++ 10 files changed, 780 insertions(+), 0 deletions(-) create mode 100644 cpufreq/test_01.sh create mode 100644 cpufreq/test_02.sh create mode 100644 cpufreq/test_03.sh create mode 100644 cpufreq/test_04.sh create mode 100644 cpufreq/test_05.sh create mode 100644 cpufreq/test_06.sh create mode 100644 utils/Makefile create mode 100644 utils/cpucycle.c create mode 100644 utils/nanosleep.c -- 1.7.4.1

14 years

[PATCH 6/11] HWMON: DA9052 hwmon driver v2

by ashishj3

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. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- Changes since v1: - Corrected error handling in the function da9052_read_vddout() --- Documentation/hwmon/da9052 | 58 ++++++++ drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/da9052-hwmon.c | 332 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 401 insertions(+), 0 deletions(-) create mode 100755 Documentation/hwmon/da9052 create mode 100755 drivers/hwmon/da9052-hwmon.c diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052 new file mode 100755 index 0000000..0b7930f --- /dev/null +++ b/Documentation/hwmon/da9052 @@ -0,0 +1,58 @@ +Kernel driver da9052-hwmon +========================== + +Supported chips: + * Dialog Semiconductors DA9052 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 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. Voltages in millivolts are 1.465 +times the ADC value. + +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 3236a45..da5ff6d 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -303,6 +303,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 HWMON" + depends on PMIC_DA9052 + help + Say y here to support the ADC found on + Dialog Semiconductor DA9052 PMIC. + + This driver can also be built as module. If so, the module + will be called da9052-hwmon. + config SENSORS_I5K_AMB tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets" depends on PCI && EXPERIMENTAL diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index f7c0c28..88b81ca 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -42,6 +42,7 @@ obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o obj-$(CONFIG_SENSORS_PKGTEMP) += pkgtemp.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 100755 index 0000000..ed25ba9 --- /dev/null +++ b/drivers/hwmon/da9052-hwmon.c @@ -0,0 +1,332 @@ +/* + * HWMON Driver for Dialog 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/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 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", 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_temperature_read(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", 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", 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; + + 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 */ + 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", 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_ICH); +static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO, show_label, NULL, + DA9052_ADC_ICH); +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 = kzalloc(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: + kfree(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); + kfree(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, + }, +}; + +static int __init da9052_hwmon_init(void) +{ + return platform_driver_register(&da9052_hwmon_driver); +} +module_init(da9052_hwmon_init); + +static void __exit da9052_hwmon_exit(void) +{ + platform_driver_unregister(&da9052_hwmon_driver); +} +module_exit(da9052_hwmon_exit); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("DA9052 HWMON driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-hwmon");

14 years

Re: Linaro 11.06 released

by Joey Stanford

Excellent work everyone. This is a superb release! On Thu, Jun 30, 2011 at 2:16 PM, Fathi Boudra <fathi.boudra(a)linaro.org> wrote: > Hi, > > The Linaro Team is pleased to announce the release of Linaro 11.06. > > 11.06 is the Linaro’s first release delivered on the new monthly cadence. > Since we started focusing on monthly component releases, activity in the > engineering teams has been channeled into producing a coherent set of packages; > This allows anyone to witness development of new features and fixes as the team > progresses towards its goals. This month’s release highlights the results: > a host of new components are now available, including LAVA packages from the > Platform Validation Team, a collection of SoC-specific kernels provided by the > Landing Teams, and preview releases of Graphics and Multimedia Working Groups > work ranging from Unity 3D to a NEON-optimized libjpeg-turbo. In addition, > another solid set of toolchain components, topped by a Linaro GCC 4.6 release > that should start making a very good impressions on benchmarks near you. > > We encourage everybody to use the 11.06 release. The download links for all > images and components are available on our release page: > > http://wiki.linaro.org/Cycles/1106/Release > > Highlights of this release: > > * Linaro Evaluation Builds (LEBs) for Ubuntu comes with the full 3D Unity > desktop experience enabled on PandaBoard. It's powered by Compiz and relies > on the Nux toolkit for its rendering. > * Linaro Evaluation Build (LEBs) for Android on Pandaboard comes with latest > stable 2.6.38 kernel from Linaro's TI Landing Team and is built using > Linaro's GCC 4.5 2011.06 release; Also, latest Linaro toolchain have been > packaged for Android and benchmark results showing noticeable performance > gains compared to the Google AOSP gingerbread toolchain have been included > as part of the release documentation: http://bit.ly/jTAhWa > * Initial preview releases of Ubuntu Hardware Packs for Snowball, Origen and > Quickstart boards featuring the latest Linaro Landing Team components are > available as part of this release. > * Linaro GCC 4.6 2011.06 and GCC 4.5 2011.06 come with bugfixes and various > performance optimizations with focus on vectoriser improvements. With this > release Linaro GCC 4.5 series enters maintenance mode and will ensure that > development can be focused on making the "future" better. > * Linaro QEMU 2011.06, based on upstream (trunk) QEMU. This version includes a > number of ARM-focused bug fixes and enhancements like the support of a model > of the Gumstix Overo board and the USB keyboard/mouse support on > BeagleBoard. > * Linaro Kernel 2.6.39 2011.06, based on the 2.6.39.1 stable kernel with a > number of changes developed by Linaro and integrated from the 3.0-rc. It > includes the ability to append Device Tree to zImage at build time, support > for parallel async MMC requests and more... > * Linaro U-Boot 2011.06.1, based on upstream version 2011.06-rc3 features USB, > Network and TFTP boot for PandaBoard as well as initial PXE support. > * First full release of LAVA components, Linaro's automated validation > solution, has been made available as part of our monthly releases. > * QEMU with OpenGL ES acceleration - technology preview. For more details, > please visit https://wiki.linaro.org/Platform/DevPlatform/QemuOpenGLES > * The Unity, NUX and Compiz port for EGL/OpenGL ES v2 that are part of > our Ubuntu LEB for this month are also made available as components > maintained by Linaro's Graphics Working Group. > * Linaro Image Tools 2011.06-1 features the support for the --image_file > option in linaro-android-media-create and support the new upstream name of > the smdkv310 SPL. > * Powerdebug 0.5-2011.06 is a major rewrite of the code to put in place a > generic framework to integrate more easily new components like the thermal > sensors. It's more modular and decrease the dependency between the display > and the power management blocks. > * And much more... The release details are linked from the "Details" column > for each release artifact on the 11.06 release page. > > Using the Android-based images > ============================== > > The Android-based images come in three parts: system, userdata and boot. > These need to be combined to form a complete Android install. For an > explanation of how to do this please see: > > http://wiki.linaro.org/Platform/Android/ImageInstallation > > If you are interested in getting the source and building these images > yourself please see the following pages: > > http://wiki.linaro.org/Platform/Android/GetSource > http://wiki.linaro.org/Platform/Android/BuildSource > > Using the Ubuntu-based images > ============================= > > The Ubuntu-based images consist of two parts. The first part is a hardware > pack, which can be found under the hwpacks directory and contains hardware > specific packages (such as the kernel and bootloader). The second part is > the rootfs, which is combined with the hardware pack to create a complete > image. For more information on how to create an image please see: > > http://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation > > Getting involved > ================ > > More information on Linaro can be found on our websites: > > * Homepage: http://www.linaro.org > * Wiki: http://wiki.linaro.org > > Also subscribe to the important Linaro mailing lists and join our IRC > channels to stay on top of Linaro developments: > > * Announcements: > http://lists.linaro.org/mailman/listinfo/linaro-announce > * Development: > http://lists.linaro.org/mailman/listinfo/linaro-dev > * IRC: > #linaro on irc.linaro.org or irc.freenode.net > #linaro-android irc.linaro.org or irc.freenode.net > > Known issues with this release > ============================== > > For any errata issues, please see: > > http://wiki.linaro.org/Cycles/1106/Release#Known_Issues > > Bug reports for this release should be filed in Launchpad against the > individual packages that are affected. If a suitable package cannot be > identified, feel free to assign them to: > > http://www.launchpad.net/linaro > > Cheers, > > -- > Fathi Boudra > Linaro Release Manager | Platform Project Manager > Linaro.org | Open source software for ARM SoCs > > _______________________________________________ > linaro-announce mailing list > linaro-announce(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-announce >

14 years

lava-dev-tool + lava-server installation/development and local data

by Zygmunt Krynicki

Hi. This is just a reminder for Michael but I think it's worth to share that to the rest of the validation team. When using lava-dev-tool to hack on lava-dashboard or any other component that is based on lava-server the location of the database and the actual data contained is easily lost. I think we need to stop using the "development" settings quickly and switch to django-debian based model where we just use a different configuration file for local development. This would make the testing environment much more similar to production (definitely django-debian would see more testing this way) and would help us locate and control application state. I would like to propose the following changes: When hacking lava-server would setup the following stuff (all relative to localenv root). /etc/lava-server/default_database.conf <- location of the database /etc/lava-server/settings.conf <- django-debian way to alter settings.py /var/lib/lava-server/media/ <- upload root /var/lib/lava-server/static/ <- django-staticfiles root /var/lib/lava-server/database.db (only when using sqlite) For postgresql (which I would like to use more by default) this is roughly the same except for default_database.conf pointing at something else than the file mentioned earlier. I'll see how I can make that happen in practice. Thanks ZK

14 years

LAVA 2011.06 Release

by Paul Larson

The Linaro Validation team is pleased to announce the first full release of LAVA, for the 2011.06 milestone. LAVA is the Linaro Automated Validation Architecture that Linaro is deploying to automate the testing of Linaro images and components on supported development boards. The release pages with release notes, highlights, changelogs, and downloads can be found at: * lava-dashboard - https://launchpad.net/lava-dashboard/linaro-11.11/2011.06 * lava-dashboard-tool - https://launchpad.net/lava-dashboard-tool/linaro-11.11/2011.06 * lava-dispatcher - https://launchpad.net/lava-dispatcher/linaro-11.11/2011.06 * lava-scheduler - https://launchpad.net/lava-scheduler/linaro-11.11/2011.06 * lava-scheduler-tool - https://launchpad.net/lava-scheduler-tool/linaro-11.11/2011.06 * lava-server - https://launchpad.net/lava-server/linaro-11.11/2011.06 * lava-test - https://launchpad.net/lava-test/linaro-11.11/2011.06 * lava-tool - https://launchpad.net/lava-tool/linaro-11.11/2011.06 * linaro-python-dashboard-bundle - https://launchpad.net/linaro-python-dashboard-bundle/linaro-11.11/2011.06 * linaro-django-xmlrpc - https://launchpad.net/linaro-django-xmlrpc/+milestone/2011.06 For more information about installing, running, and developing on LAVA, see: https://wiki.linaro.org/Platform/Validation/LAVA/Documentation Thanks, Paul Larson

14 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev June 2011