linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

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

13 years, 10 months

[PATCH v4] Add ARM cpu topology definition

by Vincent Guittot

The affinity between ARM processors is defined in the MPIDR register. We can identify which processors are in the same cluster, and which ones have performance interdependency. We can define the cpu topology of ARM platform, that is then used by sched_mc and sched_smt. The default state of sched_mc and sched_smt config is disable. When enabled, the behavior of the scheduler can be modified with sched_mc_power_savings and sched_smt_power_savings sysfs interfaces. Changes since v3 : * Update the format of printk message * Remove blank line Changes since v2 : * Update the commit message and some comments Changes since v1 : * Update the commit message * Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h * Modify header of arch/arm/kernel/topology.c * Modify tests and manipulation of MPIDR's bitfields * Modify the place and dependancy of the config * Modify Noop functions Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria(a)linaro.org> --- arch/arm/Kconfig | 25 +++++++ arch/arm/include/asm/cputype.h | 6 ++ arch/arm/include/asm/topology.h | 33 +++++++++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/smp.c | 6 ++ arch/arm/kernel/topology.c | 149 +++++++++++++++++++++++++++++++++++++++ 6 files changed, 220 insertions(+), 0 deletions(-) create mode 100644 arch/arm/kernel/topology.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9adc278..f327e55 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1344,6 +1344,31 @@ config SMP_ON_UP If you don't know what to do here, say Y. +config ARM_CPU_TOPOLOGY + bool "Support cpu topology definition" + depends on SMP && CPU_V7 + default y + help + Support ARM cpu topology definition. The MPIDR register defines + affinity between processors which is then used to describe the cpu + topology of an ARM System. + +config SCHED_MC + bool "Multi-core scheduler support" + depends on ARM_CPU_TOPOLOGY + help + Multi-core scheduler support improves the CPU scheduler's decision + making when dealing with multi-core CPU chips at a cost of slightly + increased overhead in some places. If unsure say N here. + +config SCHED_SMT + bool "SMT scheduler support" + depends on ARM_CPU_TOPOLOGY + help + Improves the CPU scheduler's decision making when dealing with + MultiThreading at a cost of slightly increased overhead in some + places. If unsure say N here. + config HAVE_ARM_SCU bool depends on SMP diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h index cd4458f..cb47d28 100644 --- a/arch/arm/include/asm/cputype.h +++ b/arch/arm/include/asm/cputype.h @@ -8,6 +8,7 @@ #define CPUID_CACHETYPE 1 #define CPUID_TCM 2 #define CPUID_TLBTYPE 3 +#define CPUID_MPIDR 5 #define CPUID_EXT_PFR0 "c1, 0" #define CPUID_EXT_PFR1 "c1, 1" @@ -70,6 +71,11 @@ static inline unsigned int __attribute_const__ read_cpuid_tcmstatus(void) return read_cpuid(CPUID_TCM); } +static inline unsigned int __attribute_const__ read_cpuid_mpidr(void) +{ + return read_cpuid(CPUID_MPIDR); +} + /* * Intel's XScale3 core supports some v6 features (supersections, L2) * but advertises itself as v5 as it does not support the v6 ISA. For diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h index accbd7c..63a7454 100644 --- a/arch/arm/include/asm/topology.h +++ b/arch/arm/include/asm/topology.h @@ -1,6 +1,39 @@ #ifndef _ASM_ARM_TOPOLOGY_H #define _ASM_ARM_TOPOLOGY_H +#ifdef CONFIG_ARM_CPU_TOPOLOGY + +#include <linux/cpumask.h> + +struct cputopo_arm { + int thread_id; + int core_id; + int socket_id; + cpumask_t thread_sibling; + cpumask_t core_sibling; +}; + +extern struct cputopo_arm cpu_topology[NR_CPUS]; + +#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id) +#define topology_core_id(cpu) (cpu_topology[cpu].core_id) +#define topology_core_cpumask(cpu) (&(cpu_topology[cpu].core_sibling)) +#define topology_thread_cpumask(cpu) (&(cpu_topology[cpu].thread_sibling)) + +#define mc_capable() (cpu_topology[0].socket_id != -1) +#define smt_capable() (cpu_topology[0].thread_id != -1) + +void init_cpu_topology(void); +void store_cpu_topology(unsigned int cpuid); +const struct cpumask *cpu_coregroup_mask(unsigned int cpu); + +#else + +static inline void init_cpu_topology(void) { }; +static inline void store_cpu_topology(unsigned int cpuid) { }; + +#endif + #include <asm-generic/topology.h> #endif /* _ASM_ARM_TOPOLOGY_H */ diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile index a5b31af..816a481 100644 --- a/arch/arm/kernel/Makefile +++ b/arch/arm/kernel/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_IWMMXT) += iwmmxt.o obj-$(CONFIG_CPU_HAS_PMU) += pmu.o obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt +obj-$(CONFIG_ARM_CPU_TOPOLOGY) += topology.o ifneq ($(CONFIG_ARCH_EBSA110),y) obj-y += io.o diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 344e52b..3e8dc3b 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -31,6 +31,7 @@ #include <asm/cacheflush.h> #include <asm/cpu.h> #include <asm/cputype.h> +#include <asm/topology.h> #include <asm/mmu_context.h> #include <asm/pgtable.h> #include <asm/pgalloc.h> @@ -268,6 +269,9 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid) struct cpuinfo_arm *cpu_info = &per_cpu(cpu_data, cpuid); cpu_info->loops_per_jiffy = loops_per_jiffy; + + store_cpu_topology(cpuid); + } /* @@ -354,6 +358,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus) { unsigned int ncores = num_possible_cpus(); + init_cpu_topology(); + smp_store_cpu_info(smp_processor_id()); /* diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c new file mode 100644 index 0000000..e8f3b95 --- /dev/null +++ b/arch/arm/kernel/topology.c @@ -0,0 +1,149 @@ +/* + * arch/arm/kernel/topology.c + * + * Copyright (C) 2011 Linaro Limited. + * Written by: Vincent Guittot + * + * based on arch/sh/kernel/topology.c + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +#include <linux/cpu.h> +#include <linux/cpumask.h> +#include <linux/init.h> +#include <linux/percpu.h> +#include <linux/node.h> +#include <linux/nodemask.h> +#include <linux/sched.h> + +#include <asm/cputype.h> +#include <asm/topology.h> + +#define MPIDR_SMP_BITMASK (0x3 << 30) +#define MPIDR_SMP_VALUE (0x2 << 30) + +#define MPIDR_MT_BITMASK (0x1 << 24) + +/* + * These masks reflect the current use of the affinity levels. + * The affinity level can be up to 16 bits according to ARM ARM + */ + +#define MPIDR_LEVEL0_MASK 0x3 +#define MPIDR_LEVEL0_SHIFT 0 + +#define MPIDR_LEVEL1_MASK 0xF +#define MPIDR_LEVEL1_SHIFT 8 + +#define MPIDR_LEVEL2_MASK 0xFF +#define MPIDR_LEVEL2_SHIFT 16 + +struct cputopo_arm cpu_topology[NR_CPUS]; + +const struct cpumask *cpu_coregroup_mask(unsigned int cpu) +{ + return &(cpu_topology[cpu].core_sibling); +} + +/* + * store_cpu_topology is called at boot when only one cpu is running + * and with the mutex cpu_hotplug.lock locked, when several cpus have booted, + * which prevents simultaneous write access to cpu_topology array + */ +void store_cpu_topology(unsigned int cpuid) +{ + struct cputopo_arm *cpuid_topo = &(cpu_topology[cpuid]); + unsigned int mpidr; + unsigned int cpu; + + /* If the cpu topology has been already set, just return */ + if (cpuid_topo->core_id != -1) + return; + + mpidr = read_cpuid_mpidr(); + + /* create cpu topology mapping */ + if ((mpidr & MPIDR_SMP_BITMASK) == MPIDR_SMP_VALUE) { + /* + * This is a multiprocessor system + * multiprocessor format & multiprocessor mode field are set + */ + + if (mpidr & MPIDR_MT_BITMASK) { + /* core performance interdependency */ + cpuid_topo->thread_id = ((mpidr >> MPIDR_LEVEL0_SHIFT) + & MPIDR_LEVEL0_MASK); + cpuid_topo->core_id = ((mpidr >> MPIDR_LEVEL1_SHIFT) + & MPIDR_LEVEL1_MASK); + cpuid_topo->socket_id = ((mpidr >> MPIDR_LEVEL2_SHIFT) + & MPIDR_LEVEL2_MASK); + } else { + /* largely independent cores */ + cpuid_topo->thread_id = -1; + cpuid_topo->core_id = ((mpidr >> MPIDR_LEVEL0_SHIFT) + & MPIDR_LEVEL0_MASK); + cpuid_topo->socket_id = ((mpidr >> MPIDR_LEVEL1_SHIFT) + & MPIDR_LEVEL1_MASK); + } + } else { + /* + * This is an uniprocessor system + * we are in multiprocessor format but uniprocessor system + * or in the old uniprocessor format + */ + + cpuid_topo->thread_id = -1; + cpuid_topo->core_id = 0; + cpuid_topo->socket_id = -1; + } + + /* update core and thread sibling masks */ + for_each_possible_cpu(cpu) { + struct cputopo_arm *cpu_topo = &(cpu_topology[cpu]); + + if (cpuid_topo->socket_id == cpu_topo->socket_id) { + cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, + &cpuid_topo->core_sibling); + + if (cpuid_topo->core_id == cpu_topo->core_id) { + cpumask_set_cpu(cpuid, + &cpu_topo->thread_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, + &cpuid_topo->thread_sibling); + } + } + } + smp_wmb(); + + printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n", + cpuid, cpu_topology[cpuid].thread_id, + cpu_topology[cpuid].core_id, + cpu_topology[cpuid].socket_id, mpidr); +} + +/* + * init_cpu_topology is called at boot when only one cpu is running + * which prevent simultaneous write access to cpu_topology array + */ +void init_cpu_topology(void) +{ + unsigned int cpu; + + /* init core mask */ + for_each_possible_cpu(cpu) { + struct cputopo_arm *cpu_topo = &(cpu_topology[cpu]); + + cpu_topo->thread_id = -1; + cpu_topo->core_id = -1; + cpu_topo->socket_id = -1; + cpumask_clear(&cpu_topo->core_sibling); + cpumask_clear(&cpu_topo->thread_sibling); + } + smp_wmb(); +} -- 1.7.4.1

13 years, 10 months

[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

13 years, 10 months

[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

13 years, 10 months

Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011

by Jesse Barker

We have both desktop (for general graphics/media stuff) and mobile tracks at this year's LPC. So if you're working on a topic related to one of the above areas, especially one that has open issues or spans multiple parts of the stack, please submit a topic for discussion at http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new against the appropriate track. If you've already submitted a talk to one of these tracks, you will likely be hearing from us over the next week. We're passed earlybird registration, but you can still sign up and attend. Thanks, Jesse Barker, desktop track lead Daniel Stone, mobile track lead

13 years, 10 months

[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

13 years, 10 months

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

13 years, 10 months

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 >

13 years, 10 months

Pandaboard broken in Linus' git tree

by john stultz

Booting Panda with Linus' current git tree (3.0-rc5-130) and got the following: [ 2.066558] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.073730] Unhandled fault: imprecise external abort (0x1406) at 0x00000000 [ 2.081146] Internal error: : 1406 [#1] SMP [ 2.085540] Modules linked in: [ 2.088775] CPU: 0 Not tainted (3.0.0-rc5-00130-g0e90ed0 #27) [ 2.095184] PC is at omap_usbhs_enable+0x174/0x43c [ 2.100250] LR is at __pm_runtime_resume+0x58/0x60 [ 2.105285] pc : [<c03450f4>] lr : [<c033dc68>] psr: 80000093 [ 2.105316] sp : ef833e50 ip : ef833e10 fp : ef833ed8 [ 2.117401] r10: 8000001c r9 : efb04f20 r8 : 80000013 [ 2.122894] r7 : efa6b724 r6 : c0718928 r5 : efb02808 r4 : efa6b6e0 [ 2.129760] r3 : 00000000 r2 : 8000001c r1 : 00000001 r0 : 00000000 [ 2.136627] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kel [ 2.144439] Control: 10c5387d Table: 8000404a DAC: 00000015 [ 2.150482] Process swapper (pid: 1, stack limit = 0xef8322f0) [ 2.156616] Stack: (0xef833e50 to 0xef834000) [ 2.161193] 3e40: eef3e000 efb02808 efb0c [ 2.169830] 3e60: 00000003 efb04f20 efb04f60 c03c9d48 c0722ccc ef832000 c0724 [ 2.178436] 3e80: 00000002 00000000 eee43208 ef833ed8 eee43208 c0176c64 fc06d [ 2.187042] 3ea0: eee43208 eee43208 00000000 eee43288 efb05e88 00000001 00000 [ 2.195678] 3ec0: 00000000 c0177eb0 ef8313c0 c05262d0 ef8556b8 00000003 73752 [ 2.204284] 3ee0: c0738ca4 efb02808 efb0283c c0738ca4 c0738ca4 00000000 00000 [ 2.212890] 3f00: 00000000 c0337dcc efb02808 c0336bf8 efb02808 efb0283c c0730 [ 2.221527] 3f20: 00000000 c0336d1c c0738ca4 ef833f38 c0336cb4 c0336424 ef850 [ 2.230133] 3f40: c0738ca4 c0738ca4 eee44d40 c072fba8 00000000 c0335d54 c0670 [ 2.238739] 3f60: 00000000 c0738ca4 c0c9a8e8 c0055894 00000000 00000000 0000c [ 2.247344] 3f80: c0c9a33c c0c9a8e8 c0055894 00000000 00000000 c0029478 00000 [ 2.255981] 3fa0: 00000000 c0033438 c00293d8 c004a570 00000000 c0170000 c065a [ 2.264587] 3fc0: c071de0c c0033438 c0033570 c0055894 00000013 00000000 00000 [ 2.273193] 3fe0: 00000000 c00083ac 00000000 c0008324 c0055894 c0055894 ffff0 [ 2.281829] [<c03450f4>] (omap_usbhs_enable+0x174/0x43c) from [<eef3e000>] () [ 2.290252] Code: e3530001 03caaa01 138aaa01 ea00005c (e59f22b0) [ 2.296691] ------------[ cut here ]------------ [ 2.301574] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:106 l3_interrupt_h) [ 2.310729] CUSTOM SRESP error with SOURCE:L4CFG [ 2.315582] Modules linked in: [ 2.318817] ---[ end trace 90068a0c409412d0 ]--- [ 2.323699] ---[ end trace 90068a0c409412d1 ]--- [ 2.328582] Kernel panic - not syncing: Attempted to kill init! [ 2.334838] CPU1: stopping Since we're likely to be moving to 3.0 for the next release, it might be good to try to get this fixed upstream. thanks -john

13 years, 10 months

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

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev