linaro-dev October 2012

linaro-dev@lists.linaro.org

76 participants
108 discussions

Booting linux-linaro-2.6.37 on Beagle Board

by Avik Sil

Hi, I tried booting linux-linaro-2.6.37 kernel on my beagle board C4. I executed following: 1. Installed linaro on a 4 GB SD card using linaro-image-tools 0.4.1 with hwpack daily snapshot hwpack_linaro-omap3_20110125-0_armel_supported.tar.gz and linaro-natty-headless-tar-20101202-1.tar.gz. It was booting properly on my BB. 2. Cloned linux-linaro-2.6.37. Changed to source directory 3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig 4. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig (enabled EARLY_PRINTK) 5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage 6. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules 7. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install INSTALL_MOD_PATH=/media/rootfs 8. cp arch/arm/boot/uImage /media/boot; sync Everything went on smoothly. Then I put the SD card on BB and powered it on. I got a kernel panic: http://paste.ubuntu.com/560562 Please help me figuring out the problem. Is it because I didn't create uInitrd? If so, then how to create it for ARM? Regards, Avik

11 years, 9 months

[PATCH v4 00/24] Introduce Xen support on ARM (based on 3.6-rc5)

by Stefano Stabellini

Hi all, this patch series implements Xen support for ARMv7 with virtualization extensions. It allows a Linux guest to boot as dom0 and as domU on Xen on ARM. PV console, disk and network frontends and backends are all working correctly. It has been tested on a Versatile Express Cortex A15 emulator, using the latest Xen ARM developement branch (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus the "ARM hypercall ABI: 64 bit ready" patch series (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546). The patch marked with [HACK] has been dropped from this series, however you can find it here: http://marc.info/?l=linux-kernel&m=134513277823527&w=2. I am also attaching to this email the dts'es that I am currently using for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to Linux by Xen, while vexpress-virt.dts is the dts used for other domUs and it is appended in binary form to the guest kernel image. I am not sure where they are supposed to live yet, so I am just attaching them here so that people can actually try out this series if they want to. Comments are very welcome! Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not present" touches generic ARM code and still needs to be acked/reviewed. Arnd, Russell, what do you think about this series? If you are OK with it, to whom should I submit it? Changes in v4: - rebase on 3.6-rc5; - devicetree: "xen,xen" should be last as it is less specific; - devicetree: use 2 address-cells and 2 size-cells in the reg property; - do not xs_reset_watches on dom0; - compile drivers/xen/pcpu.c only on x86; - use "+=" instead of ":=" for dom0- targets; - add a patch to update the MAINTAINERS file. Changes in v3: - move patches that have been picked up by Konrad at the end of the series; - improve comments; - add a doc to describe the Xen Device Tree format; - do not use xen_ulong_t for multicalls and apic_physbase; - add a patch at the end of the series to use the new __HVC macro; - add missing pvclock-abi.h include to ia64 header files; - do not use an anonymous union in struct xen_add_to_physmap. Changes in v2: - fix up many comments and commit messages; - remove the early_printk patches: rely on the emulated serial for now; - remove the xen_guest_init patch: without any PV early_printk, we don't need any early call to xen_guest_init, we can rely on core_initcall alone; - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if at the moment is unused; - use ldm instead of pop in the hypercall wrappers; - return -ENOSYS rather than -1 from the unimplemented grant_table functions; - remove the pvclock ifdef in the Xen headers; - remove include linux/types.h from xen/interface/xen.h; - replace pr_info with pr_debug in xen_guest_init; - add a new patch to introduce xen_ulong_t and use it top replace all the occurences of unsigned long in the public Xen interface; - explicitely size all the pointers to 64 bit on ARM, so that the hypercall ABI is "64 bit ready"; - clean up xenbus_init; - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI; - mark Xen guest support on ARM as EXPERIMENTAL; - introduce GRANT_TABLE_PHYSADDR; - remove unneeded initialization of boot_max_nr_grant_frames; - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c; - return -EINVAL from xen_remap_domain_mfn_range if auto_translated_physmap; - retain binary compatibility in xen_add_to_physmap: use a union to introduce foreign_domid. Shortlog and diffstat: Stefano Stabellini (24): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions docs: Xen ARM DT bindings xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_pfn_t for pfn and mfn types xen/arm: Introduce xen_ulong_t for unsigned long xen/arm: compile and run xenbus xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen: allow privcmd for HVM guests xen/arm: compile blkfront and blkback xen/arm: compile netback arm/v2m: initialize arch_timers even if v2m_timer is not present xen: missing includes xen: update xen_add_to_physmap interface MAINTAINERS: add myself as Xen ARM maintainer Documentation/devicetree/bindings/arm/xen.txt | 22 ++++ MAINTAINERS | 7 + arch/arm/Kconfig | 10 ++ arch/arm/Makefile | 1 + arch/arm/include/asm/hypervisor.h | 6 + arch/arm/include/asm/sync_bitops.h | 27 ++++ arch/arm/include/asm/xen/events.h | 18 +++ arch/arm/include/asm/xen/hypercall.h | 69 ++++++++++ arch/arm/include/asm/xen/hypervisor.h | 19 +++ arch/arm/include/asm/xen/interface.h | 73 +++++++++++ arch/arm/include/asm/xen/page.h | 82 ++++++++++++ arch/arm/mach-vexpress/v2m.c | 11 +- arch/arm/xen/Makefile | 1 + arch/arm/xen/enlighten.c | 168 +++++++++++++++++++++++++ arch/arm/xen/grant-table.c | 53 ++++++++ arch/arm/xen/hypercall.S | 106 ++++++++++++++++ arch/ia64/include/asm/xen/interface.h | 8 +- arch/x86/include/asm/xen/interface.h | 8 ++ arch/x86/xen/enlighten.c | 1 + arch/x86/xen/irq.c | 1 + arch/x86/xen/mmu.c | 3 + arch/x86/xen/xen-ops.h | 1 - drivers/block/xen-blkback/blkback.c | 1 + drivers/net/xen-netback/netback.c | 1 + drivers/net/xen-netfront.c | 1 + drivers/tty/hvc/hvc_xen.c | 2 + drivers/xen/Makefile | 13 ++- drivers/xen/events.c | 18 +++- drivers/xen/grant-table.c | 1 + drivers/xen/privcmd.c | 4 - drivers/xen/xenbus/xenbus_comms.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 62 +++++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 +- include/xen/events.h | 2 + include/xen/interface/features.h | 3 + include/xen/interface/grant_table.h | 4 +- include/xen/interface/io/protocols.h | 3 + include/xen/interface/memory.h | 21 ++-- include/xen/interface/physdev.h | 2 +- include/xen/interface/platform.h | 4 +- include/xen/interface/version.h | 2 +- include/xen/interface/xen.h | 7 +- include/xen/privcmd.h | 3 +- include/xen/xen.h | 2 +- 45 files changed, 796 insertions(+), 61 deletions(-) A branch based on 3.6-rc5 is available here: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4 Cheers, Stefano

11 years, 9 months

Planning topcs for inclusion in linux-linaro

by Jon Medhurst (Tixy)

Hi Andrey Now I'm providing a single LT topic based off linux-linaro-core-tracking (llct), and you said that you need everyone to base off the same version of llct, don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? -- Tixy

11 years, 10 months

Re: [PATCH] cpuidle: reinitialize power_usage values when adding/removing C-states

by Daniel Lezcano

On 10/17/2012 12:39 AM, Julius Werner wrote: > When cpuidle drivers do not supply explicit power_usage values, > cpuidle/driver.c inserts dummy values instead. When a running processor > dynamically gains new C-states (e.g. after ACPI events), the power_usage > values of those states will stay uninitialized, and cpuidle governors > will never choose to enter them. > > This patch moves the dummy value initialization from > cpuidle_register_driver to cpuidle_enable_device, which drivers such as > acpi/processor_idle.c will call again when they add or remove C-states. > Tested and verified on an Acer AC700 Chromebook, which supports the C3 > state only when it switches from AC to battery power. > > Signed-off-by: Julius Werner <jwerner(a)chromium.org> > --- This is specific to the acpi and should be handled in the processor_idle.c file instead of the cpuidle core code. Could be the function 'acpi_processor_cst_has_changed' the right place to set a dummy power value for the power in the new C-state ? > drivers/cpuidle/cpuidle.c | 24 ++++++++++++++++++++++++ > drivers/cpuidle/driver.c | 25 ------------------------- > 2 files changed, 24 insertions(+), 25 deletions(-) > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c > index 7f15b85..bef3a31 100644 > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -298,6 +298,28 @@ static void poll_idle_init(struct cpuidle_driver *drv) > static void poll_idle_init(struct cpuidle_driver *drv) {} > #endif /* CONFIG_ARCH_HAS_CPU_RELAX */ > > +static void set_power_states(struct cpuidle_driver *drv) > +{ > + int i; > + > + /* > + * cpuidle driver should set the drv->power_specified bit > + * before registering if the driver provides > + * power_usage numbers. > + * > + * If power_specified is not set, > + * we fill in power_usage with decreasing values as the > + * cpuidle code has an implicit assumption that state Cn > + * uses less power than C(n-1). > + * > + * With CONFIG_ARCH_HAS_CPU_RELAX, C0 is already assigned > + * an power value of -1. So we use -2, -3, etc, for other > + * c-states. > + */ > + for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) > + drv->states[i].power_usage = -1 - i; > +} > + > /** > * cpuidle_enable_device - enables idle PM for a CPU > * @dev: the CPU > @@ -330,6 +352,8 @@ int cpuidle_enable_device(struct cpuidle_device *dev) > cpuidle_enter_tk : cpuidle_enter; > > poll_idle_init(drv); > + if (!drv->power_specified) > + set_power_states(drv); > > if ((ret = cpuidle_add_state_sysfs(dev))) > return ret; > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c > index 87db387..caaed27 100644 > --- a/drivers/cpuidle/driver.c > +++ b/drivers/cpuidle/driver.c > @@ -18,28 +18,6 @@ static struct cpuidle_driver *cpuidle_curr_driver; > DEFINE_SPINLOCK(cpuidle_driver_lock); > int cpuidle_driver_refcount; > > -static void set_power_states(struct cpuidle_driver *drv) > -{ > - int i; > - > - /* > - * cpuidle driver should set the drv->power_specified bit > - * before registering if the driver provides > - * power_usage numbers. > - * > - * If power_specified is not set, > - * we fill in power_usage with decreasing values as the > - * cpuidle code has an implicit assumption that state Cn > - * uses less power than C(n-1). > - * > - * With CONFIG_ARCH_HAS_CPU_RELAX, C0 is already assigned > - * an power value of -1. So we use -2, -3, etc, for other > - * c-states. > - */ > - for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) > - drv->states[i].power_usage = -1 - i; > -} > - > /** > * cpuidle_register_driver - registers a driver > * @drv: the driver > @@ -58,9 +36,6 @@ int cpuidle_register_driver(struct cpuidle_driver *drv) > return -EBUSY; > } > > - if (!drv->power_specified) > - set_power_states(drv); > - > cpuidle_curr_driver = drv; > > spin_unlock(&cpuidle_driver_lock); -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

11 years, 10 months

[PATCH v2 0/3] EXYNOS: Add support for Exynos4x12

by Chander Kashyap

This patch series popultes Register addresses, clock structure and gpio structure for Exynos4x12. Changes in v2: - Fixed the GPIO base address macro for exynos4x12_gpio_part3_get_nr in arch/arm/include/asm/arch-exynos/gpio.h Chander Kashyap (3): EXYNOS: EXYNOS4X12: Populate Exynos4x12 register addresses EXYNOS: EXYNOS4X12: Add clock structure for EXYNOS4X12 EXYNOS: EXYNOS4X12: Add gpio structure for EXYNOS4X12 arch/arm/include/asm/arch-exynos/clock.h | 276 ++++++++++++++++++++++++++++++ arch/arm/include/asm/arch-exynos/cpu.h | 48 +++++- arch/arm/include/asm/arch-exynos/gpio.h | 85 +++++++++ 3 files changed, 402 insertions(+), 7 deletions(-) -- 1.7.9.5

11 years, 10 months

[PATCH 1/2] cpufreq: return early from __cpufreq_driver_getavg()

by Viresh Kumar

There is no need to do cpufreq_get_cpu() and cpufreq_put_cpu() for drivers that don't support getavg() routine. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 85df538..f552d5f 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1511,12 +1511,14 @@ int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu) { int ret = 0; + if (!(cpu_online(cpu) && cpufreq_driver->getavg)) + return 0; + policy = cpufreq_cpu_get(policy->cpu); if (!policy) return -EINVAL; - if (cpu_online(cpu) && cpufreq_driver->getavg) - ret = cpufreq_driver->getavg(policy, cpu); + ret = cpufreq_driver->getavg(policy, cpu); cpufreq_cpu_put(policy); return ret; -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

[RFC 0/6] sched: packing small tasks

by Vincent Guittot

Hi, This patch-set takes advantage of the new statistics that are going to be available in the kernel thanks to the per-entity load-tracking: http://thread.gmane.org/gmane.linux.kernel/1348522. It packs the small tasks in as few as possible CPU/Cluster/Core. The main goal of packing small tasks is to reduce the power consumption by minimizing the number of power domain that are used. The packing is done in 2 steps: The 1st step looks for the best place to pack tasks on a system according to its topology and it defines a pack buddy CPU for each CPU if there is one available. The policy for setting a pack buddy CPU is that we pack at all levels where the power line is not shared by groups of CPUs. For describing this capability, a new flag has been introduced SD_SHARE_POWERLINE that is used to describe where CPUs of a scheduling domain are sharing their power rails. This flag has been set in all sched_domain in order to keep unchanged the default behaviour of the scheduler. In a 2nd step, the scheduler checks the load level of the task which wakes up and the business of the buddy CPU. Then, It can decide to migrate the task on the buddy. The patch-set has been tested on ARM platforms: quad CA-9 SMP and TC2 HMP (dual CA-15 and 3xCA-7 cluster). For ARM platform, the results have demonstrated that it's worth packing small tasks at all topology levels. The performance tests have been done on both platforms with sysbench. The results don't show any performance regressions. These results are aligned with the policy which uses the normal behavior with heavy use cases. test: sysbench --test=cpu --num-threads=N --max-requests=R run Results below is the average duration of 3 tests on the quad CA-9. default is the current scheduler behavior (pack buddy CPU is -1) pack is the scheduler with the pack mecanism | default | pack | ----------------------------------- N=8; R=200 | 3.1999 | 3.1921 | N=8; R=2000 | 31.4939 | 31.4844 | N=12; R=200 | 3.2043 | 3.2084 | N=12; R=2000 | 31.4897 | 31.4831 | N=16; R=200 | 3.1774 | 3.1824 | N=16; R=2000 | 31.4899 | 31.4897 | ----------------------------------- The power consumption tests have been done only on TC2 platform which has got accessible power lines and I have used cyclictest to simulate small tasks. The tests show some power consumption improvements. test: cyclictest -t 8 -q -e 1000000 -D 20 & cyclictest -t 8 -q -e 1000000 -D 20 The measurements have been done during 16 seconds and the result has been normalized to 100 | CA15 | CA7 | total | ------------------------------------- default | 100 | 40 | 140 | pack | <1 | 45 | <46 | ------------------------------------- The A15 cluster is less power efficient than the A7 cluster but if we assume that the tasks is well spread on both clusters, we can guest estimate that the power consumption on a dual cluster of CA7 would have been for a default kernel: | CA7 | CA7 | total | ------------------------------------- default | 40 | 40 | 80 | ------------------------------------- Vincent Guittot (6): Revert "sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking" sched: add a new SD SHARE_POWERLINE flag for sched_domain sched: pack small task at wakeup sched: secure access to other CPU statistics sched: pack the idle load balance ARM: sched: clear SD_SHARE_POWERLINE arch/arm/kernel/topology.c | 5 ++ arch/ia64/include/asm/topology.h | 1 + arch/tile/include/asm/topology.h | 1 + include/linux/sched.h | 9 +-- include/linux/topology.h | 3 + kernel/sched/core.c | 13 ++-- kernel/sched/fair.c | 155 +++++++++++++++++++++++++++++++++++--- kernel/sched/sched.h | 10 +-- 8 files changed, 165 insertions(+), 32 deletions(-) -- 1.7.9.5

11 years, 10 months

[PATCH Resend V2] dt: add helper function to read u8 & u16 variables & arrays

by Viresh Kumar

This adds following helper routines: - of_property_read_u8_array() - of_property_read_u16_array() - of_property_read_u8() - of_property_read_u16() First two actually share most of the code with of_property_read_u32_array(), so the common part is taken out into a macro, which can be used by all three *_array() routines. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- V1->V2: ----- - Use typeof() in of_property_read_array() macro instead of passing type to it drivers/of/base.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------- include/linux/of.h | 30 ++++++++++++++++++++++ 2 files changed, 89 insertions(+), 14 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index af3b22a..039e178 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -670,6 +670,64 @@ struct device_node *of_find_node_by_phandle(phandle handle) } EXPORT_SYMBOL(of_find_node_by_phandle); +#define of_property_read_array(_np, _pname, _out, _sz) \ + struct property *_prop = of_find_property(_np, _pname, NULL); \ + const __be32 *_val; \ + \ + if (!_prop) \ + return -EINVAL; \ + if (!_prop->value) \ + return -ENODATA; \ + if ((_sz * sizeof(*_out)) > _prop->length) \ + return -EOVERFLOW; \ + \ + _val = _prop->value; \ + while (_sz--) \ + *_out++ = (typeof(*_out))be32_to_cpup(_val++); \ + return 0; + +/** + * of_property_read_u8_array - Find and read an array of u8 from a property. + * + * @np: device node from which the property value is to be read. + * @propname: name of the property to be searched. + * @out_value: pointer to return value, modified only if return value is 0. + * + * Search for a property in a device node and read 8-bit value(s) from + * it. Returns 0 on success, -EINVAL if the property does not exist, + * -ENODATA if property does not have a value, and -EOVERFLOW if the + * property data isn't large enough. + * + * The out_value is modified only if a valid u8 value can be decoded. + */ +int of_property_read_u8_array(const struct device_node *np, + const char *propname, u8 *out_values, size_t sz) +{ + of_property_read_array(np, propname, out_values, sz); +} +EXPORT_SYMBOL_GPL(of_property_read_u8_array); + +/** + * of_property_read_u16_array - Find and read an array of u16 from a property. + * + * @np: device node from which the property value is to be read. + * @propname: name of the property to be searched. + * @out_value: pointer to return value, modified only if return value is 0. + * + * Search for a property in a device node and read 16-bit value(s) from + * it. Returns 0 on success, -EINVAL if the property does not exist, + * -ENODATA if property does not have a value, and -EOVERFLOW if the + * property data isn't large enough. + * + * The out_value is modified only if a valid u16 value can be decoded. + */ +int of_property_read_u16_array(const struct device_node *np, + const char *propname, u16 *out_values, size_t sz) +{ + of_property_read_array(np, propname, out_values, sz); +} +EXPORT_SYMBOL_GPL(of_property_read_u16_array); + /** * of_property_read_u32_array - Find and read an array of 32 bit integers * from a property. @@ -689,20 +747,7 @@ int of_property_read_u32_array(const struct device_node *np, const char *propname, u32 *out_values, size_t sz) { - struct property *prop = of_find_property(np, propname, NULL); - const __be32 *val; - - if (!prop) - return -EINVAL; - if (!prop->value) - return -ENODATA; - if ((sz * sizeof(*out_values)) > prop->length) - return -EOVERFLOW; - - val = prop->value; - while (sz--) - *out_values++ = be32_to_cpup(val++); - return 0; + of_property_read_array(np, propname, out_values, sz); } EXPORT_SYMBOL_GPL(of_property_read_u32_array); diff --git a/include/linux/of.h b/include/linux/of.h index 72843b7..e2d9b40 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -223,6 +223,10 @@ extern struct device_node *of_find_node_with_property( extern struct property *of_find_property(const struct device_node *np, const char *name, int *lenp); +extern int of_property_read_u8_array(const struct device_node *np, + const char *propname, u8 *out_values, size_t sz); +extern int of_property_read_u16_array(const struct device_node *np, + const char *propname, u16 *out_values, size_t sz); extern int of_property_read_u32_array(const struct device_node *np, const char *propname, u32 *out_values, @@ -357,6 +361,18 @@ static inline struct device_node *of_find_compatible_node( return NULL; } +static inline int of_property_read_u8_array(const struct device_node *np, + const char *propname, u8 *out_values, size_t sz) +{ + return -ENOSYS; +} + +static inline int of_property_read_u16_array(const struct device_node *np, + const char *propname, u16 *out_values, size_t sz) +{ + return -ENOSYS; +} + static inline int of_property_read_u32_array(const struct device_node *np, const char *propname, u32 *out_values, size_t sz) @@ -463,6 +479,20 @@ static inline bool of_property_read_bool(const struct device_node *np, return prop ? true : false; } +static inline int of_property_read_u8(const struct device_node *np, + const char *propname, + u8 *out_value) +{ + return of_property_read_u8_array(np, propname, out_value, 1); +} + +static inline int of_property_read_u16(const struct device_node *np, + const char *propname, + u16 *out_value) +{ + return of_property_read_u16_array(np, propname, out_value, 1); +} + static inline int of_property_read_u32(const struct device_node *np, const char *propname, u32 *out_value) -- 1.7.12.rc2.18.g61b472e

11 years, 11 months

[PATCH 0/4] Implement device tree support for ab8500 BM Devices

by Rajanikanth H.V

From: "Rajanikanth H.V" <rajanikanth.hv(a)stericsson.com> This patch-set adds device tree binding for ab8500 battery-managed devices. Removes the redundant platform structure maintained across bm devices and implements common DT probe routine across all the modules. Test status: a) Tested across 'legacy platform data' and DT binding support a.1) ab8500_charger driver fails to get regulator in the legacy platform mode. b) Interrupt numbers assigned differs between legacy and FDT mode. (a) Legacy platform_data Mode: root@ME:/ cat /proc/interrupts CPU0 CPU1 483: 0 0 ab8500 ab8500-ponkey-dbf 484: 0 0 ab8500 ab8500-ponkey-dbr 485: 0 0 ab8500 BATT_OVV 494: 0 1 ab8500 495: 0 0 ab8500 ab8500-rtc 501: 0 13 ab8500 NCONV_ACCU 503: 7 22 ab8500 CCEOC 504: 0 1 ab8500 CC_INT_CALIB 505: 0 0 ab8500 LOW_BAT_F 516: 0 34 ab8500 ab8500-gpadc 556: 0 0 ab8500 usb-link-status (b) FDT Mode: root@ME:/ cat /proc/interrupts CPU0 CPU1 6: 0 0 ab8500 ab8500-ponkey-dbf 7: 0 0 ab8500 ab8500-ponkey-dbr 8: 0 0 ab8500 BATT_OVV 162: 0 7 ab8500 ab8500-gpadc 163: 0 1 ab8500 164: 0 0 ab8500 ab8500-rtc 484: 0 0 ab8500 usb-link-status 499: 0 4 ab8500 NCONV_ACCU 500: 0 0 ab8500 LOW_BAT_F 502: 0 1 ab8500 CC_INT_CALIB 503: 0 6 ab8500 CCEOC c) Event handlers across bm-modules have been verified only during 'battery discharge process' as 'battery charging process' depends on ab8500-usb code Rajanikanth H.V (4): mfd: ab8500: add devicetree support for fuelgauge mfd: ab8500: add devicetree support for btemp mfd: ab8500: add devicetree support for charger mfd: ab8500: add devicetree support for chargalg Documentation/devicetree/bindings/mfd/ab8500.txt | 27 +- .../bindings/power_supply/ab8500/btemp.txt | 16 + .../bindings/power_supply/ab8500/chargalg.txt | 16 + .../bindings/power_supply/ab8500/charger.txt | 25 + .../devicetree/bindings/power_supply/ab8500/fg.txt | 58 +++ arch/arm/boot/dts/dbx5x0.dtsi | 28 +- drivers/mfd/ab8500-core.c | 20 + drivers/power/Kconfig | 6 - drivers/power/Makefile | 2 +- drivers/power/ab8500_bmdata.c | 518 ++++++++++++++++++++ drivers/power/ab8500_btemp.c | 76 +-- drivers/power/ab8500_charger.c | 83 ++-- drivers/power/ab8500_fg.c | 81 +-- drivers/power/abx500_chargalg.c | 56 ++- include/linux/mfd/abx500.h | 34 +- 15 files changed, 881 insertions(+), 165 deletions(-) create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/charger.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt create mode 100644 drivers/power/ab8500_bmdata.c -- 1.7.10.4

11 years, 11 months

[PATCH] mtd: map: Fix compilation warning

by Viresh Kumar

This patch is an attempt to fix following compilation warning. In file included from drivers/mtd/chips/cfi_cmdset_0001.c:35:0: drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words': include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] I could have used uninitialized_var() too, but didn't used it as the final else part of map_word_load() is missing. So there is a chance that it might be passed uninitialized. Better initialize to zero. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- include/linux/mtd/map.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index 3595a02..56c7936 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -328,7 +328,7 @@ static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word static inline map_word map_word_load(struct map_info *map, const void *ptr) { - map_word r; + map_word r = {{0} }; if (map_bankwidth_is_1(map)) r.x[0] = *(unsigned char *)ptr; -- 1.7.12.rc2.18.g61b472e

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev October 2012