linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH 0/2] ARM: S3C64xx: cpuidle cleanups

by Daniel Lezcano

These couple of patches use the new cpuidle core api to refactor some part of the code. The first one declares the states directly in the driver declaration and the second one use the timekeeping flag to let the cpuidle core to compute the idle time. I don't have this board, I was not able to test these patches. Daniel Lezcano (2): ARM: s3c64xx: cpuidle - declare the states with the new api ARM: s3c64xx: cpuidle - use timekeeping wrapper arch/arm/mach-s3c64xx/cpuidle.c | 45 +++++++++++++-------------------------- 1 files changed, 15 insertions(+), 30 deletions(-) -- 1.7.5.4

13 years, 5 months

[PATCH 0/3] OMAP: control: bootaddr and bootmod APIs

by Omar Ramirez Luna

Recently a patch went in for tidspbridge code, to ioremap SCM registers and solve a build break[1]. However it has been pointed out before that this is a layer violation given that control module should handle its own registers, this series is an attempt to create APIs for the users of these registers. With some adaptations this patch might also make use of it: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66491.html Patch: staging: tidspbridge: use scm functions to set boot address and mode, will be sent separately to staging tree. Tested on OMAP3 Beagleboard. [1] http://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html Omar Ramirez Luna (3): OMAP2+: control: new APIs to configure boot address and mode OMAP: dsp: interface to control module functions staging: tidspbridge: use scm functions to set boot address and mode arch/arm/mach-omap2/control.c | 43 ++++++++++++++++++++ arch/arm/mach-omap2/control.h | 2 + arch/arm/mach-omap2/dsp.c | 4 ++ .../include/mach/ctrl_module_core_44xx.h | 1 + arch/arm/plat-omap/include/plat/dsp.h | 3 + drivers/staging/tidspbridge/core/tiomap3430.c | 32 +++----------- 6 files changed, 60 insertions(+), 25 deletions(-) -- 1.7.4.1

13 years, 5 months

[PATCH v4 0/7] cleanup imx5 idle, add imx5/6 cpuidle

by Robert Lee

Cleanup up imx5 idle code and enable imx5 low powe idle for imx53. Add common imx cpuidle initialization functionality and add a i.MX5 and i.MX6Q platform cpuidle implementation. Based on v3.4-rc7 plus recently submitted/accepted MACHINE_INIT late_initcall patch: http://www.spinics.net/lists/arm-kernel/msg171620.html v4 changes: * Added several imx5 idle cleanups to series. * Modified imx_io_p2v function to allow common imx5 AIPS2 bus virutal address * Added comment to tzic_wakeup_enable(). * Movied imx5 idle code from mm-imx5.c to pm-imx5.c. * Removed unnecessary time consuming code execution that ran on each idle instance. * modified imx5_pm_init to be a late_initcall * added late_initcall to all imx53 MACHINE_START entries. * enabled imx5 low power idle for imx53 * rebased cpuidle driver on top of imx5 cleanup changes. * modified cpuidle driver exit time to reflect removal of unnecessary code v3 changes: * removed file introduced in v1 no longer needed after v2 [per Shawn Guo] * re-ordered added #includes in alphabetical order [per Shawn Guo] * Remove if(!drv) check to allow handling by stack trace [per Sascha Hauer] * Added missing return value in error meesage [per Shawn Guo] * fixed (void *) casting problem pointed out Sasha Hauer. Used a different type of casting to properly give warning on improper casting: arm_pm_idle = (void (*)(void))imx5_idle; Used this casting instead of adding a dummy caller function because adding the dummy function appears to unnecessarily introduce the following additional operations: static void imx5_pm_idle(void) { a0: e1a0c00d mov ip, sp a4: e92dd800 push {fp, ip, lr, pc} a8: e24cb004 sub fp, ip, #4 imx5_idle(); ac: ebffffd3 bl 0 <imx5_idle> } b0: e89da800 ldm sp, {fp, sp, pc} http://permalink.gmane.org/gmane.linux.linaro.devel/11653 v2 changes: * Removed some unnecessary spaces [per Jess Juhl] * Added return value for an error message [per Sascha Hauer] * Reworked init scheme to use device tree late_initcall [per Sascha and Shawn] * Moved imx6q and imx5 cpuidle functionality to existing files. https://lkml.org/lkml/2012/5/1/363 v1 initial submission: https://lkml.org/lkml/2012/4/16/644 Robert Lee (7): ARM: imx: Modify IMX_IO_P2V macro ARM: imx: Add comments to tzic_enable_waker() ARM: imx: clean and consolidate imx5 suspend and idle code ARM: imx: Enable imx53 low power idle ARM: imx: Add common imx cpuidle init functionality. ARM: imx: Add imx5 cpuidle ARM: imx: Add imx6q cpuidle driver arch/arm/mach-imx/clock-mx51-mx53.c | 1 + arch/arm/mach-imx/imx53-dt.c | 1 + arch/arm/mach-imx/mach-imx6q.c | 19 ++++++ arch/arm/mach-imx/mach-mx53_ard.c | 1 + arch/arm/mach-imx/mach-mx53_evk.c | 1 + arch/arm/mach-imx/mach-mx53_loco.c | 1 + arch/arm/mach-imx/mach-mx53_smd.c | 1 + arch/arm/mach-imx/mm-imx5.c | 25 ++----- arch/arm/mach-imx/pm-imx5.c | 103 +++++++++++++++++++++-------- arch/arm/plat-mxc/Makefile | 1 + arch/arm/plat-mxc/cpuidle.c | 80 ++++++++++++++++++++++ arch/arm/plat-mxc/include/mach/common.h | 4 +- arch/arm/plat-mxc/include/mach/cpuidle.h | 22 ++++++ arch/arm/plat-mxc/include/mach/hardware.h | 25 ++++--- arch/arm/plat-mxc/tzic.c | 4 ++ 15 files changed, 231 insertions(+), 58 deletions(-) create mode 100644 arch/arm/plat-mxc/cpuidle.c create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h -- 1.7.10

13 years, 5 months

New Gator version ready for Linaro kernels

by Jon Medhurst (Tixy)

Hello All ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release. For those people maintaining kernel trees here is what this means... - If your kernels are including the linux-linaro-core-tracking [2] branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release. - For Ubuntu kernels not including linux-linaro-core-tracking (and not being released from the common linux-linaro branch) then you should replace your existing gator topic branch (or add one if it is missing). This new topic branch can be created by pulling from the ARM Landing Team's tree [3], we have tree topic branches available for the last three kernel versions... tracking-armlt-gator (3.4-rc7) 3.3-armlt-gator-5.10 3.2-armlt-gator-5.10 The code in these branches is identical, they are just rebased onto different Linux versions to make pulling easier. - For Android kernels, if your kernel already includes the Gator topic, then this should be updated as above. If it doesn't already have Gator then you can add this topic now, or, leave it for the time being. (Some Android builds are using a separate Gator git repo in their manifest and this will continue to work for now.) If anyone has any questions or if anything is unclear, please do hesitate to contact me. For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK. Cheers -- Tixy [1] Gator is the ARM target device components for ARM's Streamline Performance Analyzer which is part of their Developer Studio (DS-5). http://www.arm.com/products/tools/software-tools/ds-5/streamline.php [2] http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;… [3] git://git.linaro.org/landing-teams/working/arm/kernel.git

13 years, 5 months

Fwd: Re: FW: STM Drviers update patch

by Andy Green

-------- Original Message -------- Subject: Re: FW: STM Drviers update patch Date: Mon, 14 May 2012 21:46:40 +0800 From: Andy Green <andy.green(a)linaro.org> To: Deao, Douglas <d-deao(a)ti.com> CC: inaro-dev(a)lists.linaro.org <inaro-dev(a)lists.linaro.org>, Ryan Harkin <ryan.harkin(a)linaro.org>, Arnd Bergmann <arnd(a)arndb.de> On 14/05/12 21:41, Somebody in the thread at some point said: Hi - > The commit to my clone was right after "config tilt stm and omap driver" > on tracking-topic-stm. I used "git format-patch -1" to generate the > patch. > > I sent my patch before Ryan's showed up on the landing team site. OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to deal with it. I had Ryan's patches locally for a couple of weeks but was unable to push tracking for several days due to crash bugs I fixed late last week. > The Framework driver is not using /sys in any way, just /debugfs, so > anything with /sys was added by Ryan. You're quite right, if I looked a little further along I would have seen it's /sys/kernel/debugfs. Sorry for the noise. > The Framework driver has always had a debugfs fops API. The first > release supported only character based messages, but the new patch > supports binary transfers using the same fops API. Trying to keep > it easy to use for both cases. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 5 months

Call for perf records

by Dmitry Antipov

Hello all, I'm interesting in obtaining perf.data files recorded on a different ARM boards. For those who has no ideas about what is it, you may take a quick look at https://perf.wiki.kernel.org/index.php/Main_Page. If you're able to use apt-get or other ways to install a few packages on your board, you can help. I also prepared two perf binaries (hard- and soft-float) - if one of these matches your system, the whole procedure takes just a few minutes. 1. Make sure your kernel has tracing subsystem enabled: a) zcat /proc/config.gz and look for CONFIG_PERF_EVENTS=y, or b) check whether /sys/kernel/debug/tracing/events directory exists. 2. Install a few required packages: apt-get install libelf1 libdw1 liblzma5 binutils libbz2-1.0 zlib1g 3. Select an appropriate perf binary: a) soft-float from http://78.153.153.8/tmp/arm-linux-gnueabi-perf.gz or b) hard-float from http://78.153.153.8/tmp/arm-linux-gnueabihf-perf.gz and use ldd to check whether all runtime dependencies are resolved. 4. Run (this is one line): perf record -a -R -f -m 8192 -c 1 -e sched:sched_switch -e sched:sched_process_exit \ -e sched:sched_process_fork -e sched:sched_wakeup -e sched:sched_migrate_task ls -la / and make sure perf.data is created. 5. Run: perf report --stdio and save an output. 6. Send perf.data and output from step 5) to me, by e-mail directly or via pastebin; don't forget to mention your board type. Thanks in advance, Dmitry

13 years, 5 months

Standardized kernel interface for 2D blitters

by Ilyes Gouta

Hi, I've previously read (probably on Phoronix) that Linaro is working out a 'standard' kernel interface for 2D blitters IPs as commonly found on SoCs. Has it ever been the case? If yes, are there any documentation/references online? Thanks, -Ilyes

13 years, 5 months

Building a SINGLE driver file - A tip.

by Venkat Raghavulu

Hello All Just discovered something, wanted to share, might be that many out there will be knowing this, for the unknowns sharing this: We do few source file change and then end up building the entire stuff using "make" command. Mid way through the build we see that a single annoying COMPILE ERROR and see its such a waste of time. So the ideal thing is to just compile and link only the changed file which will be quick and rest assured FULL the build will succeed. So here's how it is to be done: In my below example I am building the Sensor file which is in the path, kernel/drivers/hwmon: *The build command is:* make -C ../out/target/product/snowball/obj/kernel/ SUBDIRS=drivers/hwmon ARCH=arm CROSS_COMPILE=arm-eabi- *Replace the "drivers/hwmon" to your location where the file you modified is present and it builds.* For eg: venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ vim drivers/hwmon/lsm303dlh_m.c venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ make -C ../out/target/product/snowball/obj/kernel/ SUBDIRS=drivers/hwmon ARCH=arm CROSS_COMPILE=arm-eabi- make: Entering directory `/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel' make -C /u/home01/venkatr/snowball_board_branch_0.0.3/kernel O=/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel/. CC drivers/hwmon/lsm303dlh_m.o LD drivers/hwmon/built-in.o Building modules, stage 2. MODPOST 0 modules make: Leaving directory `/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel' venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ BR, Venkat.

13 years, 5 months

Agenda for Linaro Android Team Meeting Posted

by Zach Pfeffer

The agenda's at: https://wiki.linaro.org/Platform/Android/Meetings/2012-05-16 Feel free to add to it, etc... For Android team members, please post your status. See you tomorrow! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 5 months

[RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code

by Javier Martinez Canillas

board_onenand_init() and board_nand_init() initialization functions are used to initialize OneNAND and NAND memories respectively. But only board_nand_init() was visible to be used from board code. This patch makes possible to initialize a OneNAND flash memory within platform code. Signed-off-by: Javier Martinez Canillas <javier(a)dowhile0.org> --- arch/arm/mach-omap2/board-flash.c | 4 ++-- arch/arm/mach-omap2/board-flash.h | 11 +++++++++++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c index 0349fd2..70a81f9 100644 --- a/arch/arm/mach-omap2/board-flash.c +++ b/arch/arm/mach-omap2/board-flash.c @@ -87,7 +87,7 @@ static struct omap_onenand_platform_data board_onenand_data = { .dma_channel = -1, /* disable DMA in OMAP OneNAND driver */ }; -static void +void __init board_onenand_init(struct mtd_partition *onenand_parts, u8 nr_parts, u8 cs) { @@ -98,7 +98,7 @@ __init board_onenand_init(struct mtd_partition *onenand_parts, gpmc_onenand_init(&board_onenand_data); } #else -static void +void __init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs) { } diff --git a/arch/arm/mach-omap2/board-flash.h b/arch/arm/mach-omap2/board-flash.h index d25503a..c44b70d 100644 --- a/arch/arm/mach-omap2/board-flash.h +++ b/arch/arm/mach-omap2/board-flash.h @@ -47,3 +47,14 @@ static inline void board_nand_init(struct mtd_partition *nand_parts, { } #endif + +#if defined(CONFIG_MTD_ONENAND_OMAP2) || \ + defined(CONFIG_MTD_ONENAND_OMAP2_MODULE) +extern void board_onenand_init(struct mtd_partition *nand_parts, + u8 nr_parts, u8 cs); +#else +static inline void board_onenand_init(struct mtd_partition *nand_parts, + u8 nr_parts, u8 cs) +{ +} +#endif -- 1.7.7.6

13 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev