linaro-dev April 2011

linaro-dev@lists.linaro.org

101 participants
154 discussions

[powerdebug 01/35] change regulator init function

by Daniel Lezcano

Move the corresponding function to the right header file and rename the function with <subsystem>_function_name. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)free.fr> --- powerdebug.c | 3 ++- powerdebug.h | 1 - regulator.c | 2 +- regulator.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/powerdebug.c b/powerdebug.c index 2f0992b..fa26e77 100644 --- a/powerdebug.c +++ b/powerdebug.c @@ -15,6 +15,7 @@ #include <getopt.h> #include <stdbool.h> +#include "regulator.h" #include "powerdebug.h" int highlighted_row; @@ -352,7 +353,7 @@ int main(int argc, char **argv) return 1; } - if (init_regulator_ds()) + if (regulator_init()) return 1; if (mainloop(options)) diff --git a/powerdebug.h b/powerdebug.h index cef5570..42add86 100644 --- a/powerdebug.h +++ b/powerdebug.h @@ -32,7 +32,6 @@ extern struct regulator_info *regulators_info; extern int numregulators; -extern int init_regulator_ds(void); extern void print_regulator_info(int verbose); extern void read_regulator_info(void); extern void print_regulator_info(int verbose); diff --git a/regulator.c b/regulator.c index 18c9777..395571b 100644 --- a/regulator.c +++ b/regulator.c @@ -15,7 +15,7 @@ #include "regulator.h" -int init_regulator_ds(void) +int regulator_init(void) { DIR *regdir; struct dirent *item; diff --git a/regulator.h b/regulator.h index 3ecf6b8..b6780ab 100644 --- a/regulator.h +++ b/regulator.h @@ -40,4 +40,4 @@ struct regulator_info { int num_users; } *regulators_info; -extern int numregulators; +extern int regulator_init(void); -- 1.7.1

14 years, 10 months

Pathes for "Produce boottarball that includes rootfs, kernel and bootloader" for Android

by Patrik Ryd

Hi, I will push some patches for review. They are all for Android. For the blueprint https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-platfo… . I have had problems setting the subject correctly, but they are for the android manifest, linaro/device/common, linaro/device/beagleboard and build gits. BR, Patrik

14 years, 10 months

[PATCH] Added missing " in build-boottarball-target

by Patrik Ryd

--- core/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/core/Makefile b/core/Makefile index 8b7d6de..857dd20 100644 --- a/core/Makefile +++ b/core/Makefile @@ -794,7 +794,7 @@ stnod: systemtarball-nodeps ####### ## boot tarball define build-boottarball-target - $(hide) echo "Target boot fs tarball: $(INSTALLED_BOOTTARBALL_TARGET) + $(hide) echo "Target boot fs tarball: $(INSTALLED_BOOTTARBALL_TARGET)" $(hide) mkdir -p $(PRODUCT_OUT)/boot $(hide) cp -f $(INTERNAL_BOOTIMAGE_FILES) $(PRODUCT_OUT)/boot/. $(hide) echo $(BOARD_KERNEL_CMDLINE) > $(PRODUCT_OUT)/boot/cmdline @@ -809,7 +809,7 @@ endif boot_tar := $(PRODUCT_OUT)/boot.tar INSTALLED_BOOTTARBALL_TARGET := $(boot_tar).$(BOOT_TARBALL_FORMAT) -$(INSTALLED_BOOTTARBALL_TARGET): PRIVATE_BOOT_TAR := $(boot_tar) +PRIVATE_BOOT_TAR := $(boot_tar) $(INSTALLED_BOOTTARBALL_TARGET): $(FS_GET_STATS) $(INTERNAL_BOOTIMAGE_FILES) $(build-boottarball-target) -- 1.7.1

14 years, 10 months

[PATCH 1/2] Enable kernel

by Patrik Ryd

Set TARGET_NO_KERNEL to false in BoardConfig --- BoardConfig.mk | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/BoardConfig.mk b/BoardConfig.mk index f0703c7..11b49a8 100644 --- a/BoardConfig.mk +++ b/BoardConfig.mk @@ -5,7 +5,8 @@ TARGET_BOARD_PLATFORM := omap3 TARGET_NO_BOOTLOADER := true -TARGET_NO_KERNEL := true +TARGET_NO_KERNEL := false +KERNEL_CONFIG := android_omap3_defconfig TARGET_NO_RADIOIMAGE := true TARGET_PROVIDES_INIT_RC := true BOARD_USES_GENERIC_AUDIO := false -- 1.7.1

14 years, 10 months

[PATCH V1] ARM: Samsung: Basic CPUIDLE Support

by Amit Daniel Kachhap

This patch supports cpuidle framework for EXYNOS4210. Currently, Only one idle state is possible to use, but more idle states can be added following by this patch. Signed-off-by: Jaecheol Lee <jc.lee(a)samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap(a)linaro.org> --- FIX: Fixed the merging issue reported by Nicolas Pitre <nicolas.pitre(a)linaro.org> Sending the rebased patch for linaro 2.6.38 kernel. This patch adds basic cpuidle infrastructure and fixes the launchpad bug(bug id: 723543). This patch is under review in samsung mailing list. http://www.spinics.net/lists/linux-samsung-soc/msg04268.html arch/arm/mach-exynos4/Makefile | 1 + arch/arm/mach-exynos4/cpuidle.c | 87 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos4/cpuidle.c diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile index b8f0e7d..f8a3a74 100644 --- a/arch/arm/mach-exynos4/Makefile +++ b/arch/arm/mach-exynos4/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o irq-combiner.o obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o gpiolib.o irq-eint.o dma.o obj-$(CONFIG_PM) += pm.o sleep.o obj-$(CONFIG_CPU_FREQ) += cpufreq.o +obj-$(CONFIG_CPU_IDLE) += cpuidle.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c new file mode 100644 index 0000000..a543a18 --- /dev/null +++ b/arch/arm/mach-exynos4/cpuidle.c @@ -0,0 +1,87 @@ +/* linux/arch/arm/mach-exynos4/cpuidle.c + * + * Copyright (c) 2011 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/cpuidle.h> +#include <linux/io.h> + +#include <asm/proc-fns.h> + +static int exynos4_enter_idle(struct cpuidle_device *dev, + struct cpuidle_state *state); + +static struct cpuidle_state exynos4_cpuidle_set[] = { + [0] = { + .enter = exynos4_enter_idle, + .exit_latency = 1, + .target_residency = 100000, + .flags = CPUIDLE_FLAG_TIME_VALID, + .name = "IDLE", + .desc = "ARM clock gating(WFI)", + }, +}; + +static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device); + +static struct cpuidle_driver exynos4_idle_driver = { + .name = "exynos4_idle", + .owner = THIS_MODULE, +}; + +static int exynos4_enter_idle(struct cpuidle_device *dev, + struct cpuidle_state *state) +{ + struct timeval before, after; + int idle_time; + + local_irq_disable(); + do_gettimeofday(&before); + + cpu_do_idle(); + + do_gettimeofday(&after); + local_irq_enable(); + idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC + + (after.tv_usec - before.tv_usec); + + return idle_time; +} + +static int __init exynos4_init_cpuidle(void) +{ + int i, max_cpuidle_state, cpu_id; + struct cpuidle_device *device; + + cpuidle_register_driver(&exynos4_idle_driver); + + for_each_cpu(cpu_id, cpu_online_mask) { + device = &per_cpu(exynos4_cpuidle_device, cpu_id); + device->cpu = cpu_id; + + device->state_count = (sizeof(exynos4_cpuidle_set) / + sizeof(struct cpuidle_state)); + + max_cpuidle_state = device->state_count; + + for (i = 0; i < max_cpuidle_state; i++) { + memcpy(&device->states[i], &exynos4_cpuidle_set[i], + sizeof(struct cpuidle_state)); + } + + if (cpuidle_register_device(device)) { + printk(KERN_ERR "CPUidle register device failed\n,"); + return -EIO; + } + } + return 0; +} + +device_initcall(exynos4_init_cpuidle); -- 1.7.1

14 years, 10 months

[PATCH] net/fec: fix compile error introduced by dt support

by Shawn Guo

After fec dt support is added, the following compile error will be seen when building a pure non-dt kernel. drivers/net/fec.c: In function ‘fec_probe’: drivers/net/fec.c:1383: error: implicit declaration of function ‘of_match_device’ drivers/net/fec.c:1383: warning: assignment makes pointer from integer without a cast This patch is to fix the error. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- drivers/net/fec.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/net/fec.c b/drivers/net/fec.c index b57f879..ffb1e75 100644 --- a/drivers/net/fec.c +++ b/drivers/net/fec.c @@ -85,8 +85,19 @@ static const struct of_device_id fec_dt_ids[] = { { .compatible = "fsl,imx51-fec", .data = &fec_devtype[0], }, {}, }; + +static const struct of_device_id * +fec_get_of_device_id(struct platform_device *pdev) +{ + return of_match_device(fec_dt_ids, &pdev->dev); +} #else #define fec_dt_ids NULL +static inline struct of_device_id * +fec_get_of_device_id(struct platform_device *pdev) +{ + return NULL; +} #endif static unsigned char macaddr[ETH_ALEN]; @@ -1380,7 +1391,7 @@ fec_probe(struct platform_device *pdev) struct resource *r; const struct of_device_id *of_id; - of_id = of_match_device(fec_dt_ids, &pdev->dev); + of_id = fec_get_of_device_id(pdev); if (of_id) pdev->id_entry = (struct platform_device_id *)of_id->data; -- 1.7.1

14 years, 10 months

Re: Linus being annoyed by the ARM kernel code

by Eric Miao

On Fri, Apr 1, 2011 at 11:57 PM, Philippe Robin <philippe.robin(a)arm.com> wrote: > Eric, > >>> So maybe it's just a right time to talk about using linaro ARM kernel >>> tree as a fork for quick merge of the ever expanding SoC and board >>> support, and using it more as a productive kernel for downstream. > > I don't think that a 'fork' is really a solution we are looking for. Using > Linaro as a staging and consolidation tree and at the same time improving > the upstream kernel is more what I would be looking for and what Linaro is > currently working on. Yeah, staging is more close to what I meant, a 'fork' is not appropriate here, as getting the support into mainline will always be our goal. Yet there seems to be necessary to have such a temporary place for those patches to live before the mainline is in a good enough shape. And it should not be an arm-next tree, which is just for detecting merge conflict. I expect it to be more usable, end users can just download and build a basically usable kernel. > > Regards, > Philippe > > -----Original Message----- > From: linaro-dev-bounces(a)lists.linaro.org > [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Eric Miao > Sent: 01 April 2011 16:44 > To: Linaro Dev > Subject: Linus being annoyed by the ARM kernel code > > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. > > - eric > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev >

14 years, 10 months

Linus being annoyed by the ARM kernel code

by Eric Miao

Just FYI - lengthy but very interesting read, Linus was really good at wording, enjoy heh :-) https://lkml.org/lkml/2011/3/17/283 So maybe it's just a right time to talk about using linaro ARM kernel tree as a fork for quick merge of the ever expanding SoC and board support, and using it more as a productive kernel for downstream. And in the mean time, improve the mainline kernel into such a good shape that with less crappy code we could support more platforms? Just a bit thought on that possibility. - eric

14 years, 10 months

armhf progress: 2.6.38 kernel for the efikasb/mx, SD card bootable image

by Konstantinos Margaritis

Hi all, I tried to upload the kernel debs to ftp.debian-ports.org, but I'm getting some upload errors, so I uploaded them to http://www.freevec.org/packages/ the armhf sd card image is finally uploaded here: http://www.freevec.org/packages/efikamx-armhf.img.xz it is very recent, includes pbuilder in case one wants to try building packages for armhf. But console only, though gnome/kde packages exist in the repo. Btw, there is no video display support for the smarttop yet, but ssh works. It includes PATA/fb/ethernet/wifi(untested). Default root password: efika, default hostname: efika-armhf Enjoy Konstantinos

14 years, 10 months

Re: Bug#616111: Bootstrapping a foreign architecture with multiarch

by Neil Williams

On Sat, 2 Apr 2011 05:47:47 +0200 Guillem Jover <guillem(a)debian.org> wrote: Adding linaro people and debian-embedded to CC: > Hi! > > On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote: > > dpkg cannot be executed inside the chroot because it has not > > necessarily been unpacked at this stage, it certainly has not been > > configured. (dpkg is running from outside the chroot). > > (An Essential package does not need to be configured to be functional.) (It's quite possibly the wrong architecture inside the chroot, so this doesn't apply.) > > Yet dpkg-query won't work with --admindir to operate from outside: I'm checking on this - it could be an artefact of how the chroot was initially created. > > Anyways: > > > > > Multi-Arch: same packages will use > > > /var/lib/dpkg/info/<package>:<arch>.<something> > > > > > > > For Multistrap, every file in /var/lib/dpkg/ has to be created by > > > > multistrap, based on the data obtained from dpkg -e (basically the > > > > DEBIAN/ content). This data needs only to be sufficient that dpkg can > > > > correctly configure the packages once dpkg itself is able to be > > > > executed inside the new filesystem. > > > > > > It's sufficient, you just need to know the value of the Multi-Arch field. > > > > True. I've got a change now which uses dpkg -f to check the Multi-Arch > > field of the actual downloaded .deb (independent of arch) and use that > > to detect Multi-Arch: same, then lookup Architecture in the same way, > > add that to the filename of the created maintainer script etc. > > for /path/to/chroot/var/lib/dpkg/info/* > > If you are not going to install multiple instances of “Multi-Arch: same” > packages, then just keep writting the files as you are currently > doing, the next dpkg native run on that chroot image will > automatically upgrade the db layout. Which seems to be the less > onerous way to handle this. Otherwise you'll have to duplicate the > db layout handling, including format file, etc, and at that point I'd > say you are on your own. Multistrap will need to be able to create chroots containing multiple instances of Multi-Arch: same packages because it needs to be able to build cross-building chroots with libc6-dev of the build and host architectures, as well as other common dependencies like libglib2.0-0 (needed as build arch by pkg-config and as host arch by everything else). Multistrap, like debootstrap and other similar scripts, is commonly used in two roles - to create a chroot of the build architecture for building stuff in a contained environment and creating a chroot of a foreign architecture to act as a root filesystem. As with debootstrap, I see no reason to implement two different methods to creating these chroots inside a single tool, so when creating a build arch chroot multistrap uses the same processing as when creating a foreign arch chroot. That processing has to avoid a design flaw in dpkg where the normal --unpack method would attempt to run the preinst scripts. > On Fri, 2011-04-01 at 22:43:35 +0100, Neil Williams wrote: > > Further to this, --control-path doesn't include 'list' but > > $pkg:$arch.list files are created. > > This was done on purpose, .list and .conffiles are internal files, the > correct interfaces to access the information is dpkg-query. Internal files maybe, but multistrap still needs to create them to handle packages of a foreign architecture. Even once Multi-Arch is fully deployed, this will continue because the assumption with Multi-Arch is that the foreign architecture packages are being installed alongside the build architecture. When preparing a root filesystem for a foreign architecture (e.g. an embedded device), multistrap cannot put the amd64 binaries into the chroot and then add the armel, it needs to be able to unpack armel binaries into an armel chroot without running the preinst scripts or using the armel dpkg binary inside the chroot. The preinst scripts can't run on the build arch (amd64) because that would expose the chroot to the external configuration. i.e. it needs to be possible to create an armel chroot of Ubuntu natty from an i386 machine running Debian Wheezy and similarly from Ubuntu natty i386 to create a Debian Wheezy armel chroot. Currently, dpkg --unpack cannot cope with this and the existing Multi-Arch changes in dpkg do not address this problem. This has been covered before in this bug and elsewhere without resolution, but please reconsider how dpkg - even in a Multi-Arch world - needs to support unpacking foreign architecture binaries into a foreign architecture chroot and that this mandates that dpkg *must not* attempt to execute the preinst scripts inside the foreign chroot. It can *only* do so if the packages are to be unpacked into the main, external, system. When using --admindir and --instdir options to --unpack, dpkg *must* allow for the specified directories to actually be a foreign architecture chroot and act accordingly. Maybe this requires the addition of an --arch option to --unpack but it *does* need to be addressed. The files being created in /var/lib/dpkg/ are not architecture-dependent, it's only dpkg which needs to understand that when creating a foreign architecture chroot, the external dpkg must not execute the preinst scripts. That is all that is required. Working out how to configure the resulting system (probably by running the preinst scripts manually with the install argument prior to running dpkg --configure -a) and whether to use an emulator or after booting, is left to the admin of the device. dpkg doesn't need to care, it simply needs to "do the right thing" when unpacking. If this doesn't change, I will simply have to continue reimplementing dpkg behaviour in multistrap and elsewhere, causing this inconsistency to continue forever. That is not helpful. Let's solve this properly at this ideal opportunity when Multi-Arch is still in final development. I don't need to be "on my own" on this one (and I'm not anyway because a lot of people need to have this behaviour from dpkg or from some other tool which can hack around dpkg to avoid this design flaw). This can't be swept under the carpet again, it needs to be addressed. dpkg --unpack NEEDS to understand that when dealing with a foreign architecture chroot it CANNOT execute the preinst scripts. I will escalate this issue further if the dpkg team claim that this functionality is not possible to implement. Now is the perfect time to fix this long standing design flaw in dpkg. On the surface, it seems a simple thing to setup: if an --arch option is used alongside --admindir and --instdir to the --unpack command, then the preinst scripts are never executed. It doesn't have to be an option called --arch (although that is probably the easiest for embedded developers to find in the dpkg man page), it could be "--no-preinst" or something. It is just plain wrong that, even with Multi-Arch, dpkg cannot be used to bootstrap a foreign architecture into a chroot and that people like me have to invent a set of hacks to duplicate what dpkg should do itself. I've done this enough times already. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2011