linaro-dev September 2010

linaro-dev@lists.linaro.org

78 participants
101 discussions

by Tom Gall

Hi All, I've started a Eclipse page https://wiki.linaro.org/Eclipse/Evaluation It's mostly meant as a place to collect Eclipse information which perhaps might drive some future blueprints. It's mostly skeleton at this point so feel free to add to it. Regards, Tom User Platforms

15 years, 12 months

Linaro Foundations Team Weekly Report (2010-09-02 to 2010-09-08)

by Steve Langasek

The weekly report for the Linaro Foundations team may be found at: Status report: https://wiki.linaro.org/Platform/Foundations/2010-09-08 Overall status: https://wiki.linaro.org/Releases/FoundationsStatus Work continues on bugfixing for the 10.11 release, as well as some spec work not affecting the archive. The burndown chart at http://people.canonical.com/~pitti/workitems/maverick/linaro-foundations.ht… shows that we are on target to complete remaining engineering work for the 10.11 release. Actions: * slangasek to follow up on bug #623478 for sponsorship * npitre to give jcrigby feedback on devicetree u-boot patches * slangasek to post DebConf 10 gobby notes publically * slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync * jcrigby, dmart to follow up on getting linux-tools to build in linaro kernel package Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

15 years, 12 months

omap3 startup memory map

by Peter Maydell

Hi. I have a question about what the memory map of the TI OMAP3 (35xx) looks like on startup, which I'm hoping somebody here can answer. (Steve, Richard: you're on the CC: because Loic suggested that you would be good people to ask.) I'm currently looking at a bug in qemu: https://bugs.launchpad.net/qemu-maemo/+bug/628471 where we hang on bootup. That happens because the qemu implementation of NAND attached to the omap GPMC doesn't try to map anything into the memory space (it only does this for NOR devices). >From reading the OMAP35xx TRM I believe that when a NAND device is mapped into GPMC space (by setting GPMC_CONFIG7_i appropriately) then reads and writes to any address in the mapped region behave like accesses to GPMC_NAND_DATA_i. I have a patch which implements this mapping for NAND devices; however this causes a conflict about what should be mapped at address zero on startup, because: (a) at reset GPMC_CONFIG7_i is 0xf40 for CS0 and 0xf00 for CS1..7, which maps CS0 to address 0. (On the Beagle board this is NAND.) (b) qemu also wants to map the boot ROM in at address 0 The TRM isn't terribly clear (to me :-)) about what happens at address zero on startup (it talks about a "1MB boot space" but doesn't say what this is or what address it is at or when it stops being in effect...) It's also possible that qemu is wrong about mapping boot rom related things at address zero; we are emulating much of what the hardware's boot ROM does rather than actually executing it. However I would expect that there ought to be some real RAM/ROM there for the reset/exception vectors if nothing else... So can anybody tell me what happens on real hardware? Thanks in advance -- Peter Maydell

15 years, 12 months

Experimental clutter packages with rectangle texture API

by Alexandros Frantzis

Hi all! I have released an experimental package of clutter that includes two additional patches (relatively to the maverick package): 1. debian/patches/remove_cogl_gl_types.patch: This patch removes all references to GL types and defines from the cogl and headers and additionally removes GL headers from cogl-defines.h. The reason for this patch is to ease cross-building of GLES2 clutter apps against libclutter-1.0-dev (instead of requiring libclutter-eglx-es20-1.0-dev). It also makes sense for Cogl (which is supposed to be an abstraction layer) to *not* force any particular GL header inclusion. The side effect of this patch is that applications that need to directly use GL functions, types etc must explicitly include the GL headers of their choice instead of relying on clutter to do this for them. This, of course, breaks some applications (clutk, mutter, gnome-shell to name a few) but the fix is trivial (just a correct GL header inclusion in the application itself). 2. debian/patches/rectangle-texture.patch: This patch exports an API for explicitly creating rectangle textures. It uses code backported from the 1.3 branch plus some additions needed to produce a complete API (eg clutter_texture_rectangle_new_from_file()). The purpose of this patch is to provide a GL-version-independent way for applications to use rectangle textures. This will make applications (eg mutter) GL agnostic and therefore make them more easy to package and use with different GL(ES) versions. Note that upstream is planning on following this approach and explicitly exporting API to create specific texture types. Hopefully, they will implement this soon :) For a simple test of this package (and especially the rectangle texture API) you can use the Cogl Basics example *with* the attached patch. The Cogl Basics examples is at: http://wiki.clutter-project.org/wiki/Cogl/CoglBasicsExample The packaging branch is at: lp:~linaro-user-platforms/ubuntu/maverick/clutter-1.0/clutter-1.0-texture-rectangle and packages are in: https://launchpad.net/~afrantzis/+archive/clutter-1.2 My next steps are to start patching clutk, mutter etc so that: a. They build. b. They make use of the rectangle texture API where needed. Any comments, feedback etc more than welcome :) Thanks, Alexandros

15 years, 12 months

I/O errors on NAND on beagle rev C3

by Loïc Minier

Hi folks I've had problem upgrading my beagleboard C3 for a while; today, I reflashed kernel and initrd, got problems loading the initrd I had written but not the kernel. Upon boot, I could see the MTDs again (in the past I couldn't anymore due to a missing config), but flash-kernel gives only I/O errors. Is anybody else seeing I/O errors to NAND with a beagleboard rev C and Linaro OMAP kernels? 2.6.35-1003-linaro-omap is what I have here I wonder whether it's the hardware being dead, or a kernel bug Thanks -- Loïc Minier

15 years, 12 months

Notes from Landing Teams call 2010/09/10

by Loïc Minier

Hi Notes from today's Landing Teams call; also at https://wiki.linaro.org/LandingTeams/Meetings/2010-09-10 Cheers === Attendees === * Loïc Minier * Torez Smith * Matt Waddel * Scott Bambrough === Agenda === * Action items from last meeting. * Achievements / progress reports * OMAP3 * Versatile Express * Meetings next weeks === Action Items === * Loïc to check what to do with broken boards * Torez to ask Mounir to add the IGEP board to Internal/Hardware wiki page * Matt to list known bugs link on Boards/Vexpress * Matt to request jcrigby to build the mouse driver in the kernel and to file a bug to track the other issue === Action Items from Previous Meeting === * Loïc to find a replacement XM for Torez * Loïc to check what to do with broken boards * Torez to add boards to Internal/Hardware wiki page === Minutes === * Action items from last meeting. * Loïc to find a replacement XM for Torez . DONE we have a spare but Stephen expects IBM to provide hardware RSN; if that does not happen, he will ship one * Loïc to check what to do with broken boards . CARRYOVER chatting with TI to decide * Torez to add boards to Internal/Hardware wiki page . CARRYOVER Torez to ask Mounir to do it * Achievements / progress reports * OMAP3 * LP #618734 - Added a patch and reassigned to jcrigby - fixes config to get ethernet working; also tested on XM, no regression * LP #619206 - libertas-firmware missing - not sure how to test wifi? * Should apt-get install wireless-tools wpasupplicant libertas-firmware * Also need to enable multiverse * LP #622429 - ethernet shows up as usb0 - oddly, IGEP as a random address, but is named eth0; investigating * LP #633338 - no LCD on IGEP - should be high prio; expects to attack it soon * Versatile Express * flash-kernel now working! yeah `\o/` * Validated kernels from Hudson * Found that framebuffer issue is known bug and you got a huge diff with the fix somewhere in it; looking into that * Will link to list of known bugs from Boards/Vexpress . ACTION Matt to list known bugs link on Boards/Vexpress * Mouse stopped working; seems to be since it moved as a module; in general, this seems to be a genuine bug, but building the driver in the kernel is probably the best workaround in the short term . ACTION Matt to request jcrigby to build the mouse driver in the kernel and to file a bug to track the other issue * Similar issue also affects Torez on IGEP's eth0 * Meetings next weeks * Loïc travelling * Matt leading the calls * Next Monday cancelled, not sure about the next one * Scott offering to lead the Monday in 10 days, but away next week * Torez proposes joining the KCWG meetings, and she's welcome to! -- Loïc Minier

16 years

Notes from Kernel Consolidation WG call 2010/09/06

by Loïc Minier

Hi folks I failed horribly at sending out emails with the notes of Kernel Consolidation WG calls in the last weeks, sorry about that. (They were pushed to the wiki though.) Please find the notes from this week's call below, as well as activity reports of people in the WG; also at: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-09-… Cheers, == Notes from call == === Attendees === * Loïc Minier * Arnd Bergmann * Dave Martin * Shajul Abraham * Jeremy Kerr * Nicolas Pitre * Grant Likely === Agenda === * Action items from last meeting. * Progress update. * Blueprint status. === Action Items === * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP * John to update DT u-boot patches * Loïc to work on kernel build infrastructure * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards * Nicolas to finish SECCOMP support * Arnd to send patches to fix all io.h copies * Nico to send feedback to jk on the DT ARM patches * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config * Arnd to document BSP review on [[BSP/STE]] or so * Nicolas to start a wiki page on recommendations for BSP authors === Action Items from Previous Meeting === * Loïc to check with Richard what's going on about these: * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP * John to update DT u-boot patches * Loïc to work on kernel build infrastructure * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards * Loïc to pass Vexpress board to Arnd * Loïc to poke amitk and other stakeholders and defer remaining things for next cycle on security features blueprint * Arnd to send patches to fix all io.h copies * Nico to send feedback to jk on the DT ARM patches this week * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config * Loïc to send out his notes on release process * Matt to file bugs and try the ARM kernel for both bugs === Minutes === * Loïc to check with Richard what's going on about these: . DONE * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP . INPROGRESS Dave started reviewing the BSP; needs to write a wiki page from it * Based on 2.6.31 * Tried applying diff from .31 to .32 * Has this huge 10 MB patch as a single commit when the kernel is moved to a new version; not clear how to move this forward * Covers much more than i.mx51 * Arnd started reviewing the ST-E BSP; the upstream version of the kernel is a bit weird, mixup of .34 and .29; saw many warnings * Discussed with Linus Walleij who said this branch is dead, but only used for current products * About 10 times more code in the BSP than upstream * Contains random other stuff which is not part of their tree * ST-Ericsson will continue porting this tree to 2.6.35 internally, Arnd thinks that .36 would be a better target * Makes direct recommendation to Linus, but it's specific to their BSP . ACTION Arnd to document BSP review on [[BSP/STE]] or so . ACTION Nicolas to start a wiki page on recommendations for BSP authors * John to update DT u-boot patches . CO * Loïc to work on kernel build infrastructure . INPROGRESSS switched to Hudson (hudson-ci.org) and got a multi-way u-boot build going; worked fine and intends to deploy, mostly needs configs to go with the kernels now :-) * Frederick started looking at the problems of configs and config policies, and will be sending mail + wiki page to linaro-dev@; Nicolas can review and comment * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards . CO * Loïc to pass Vexpress board to Arnd . DONE * Loïc to poke amitk and other stakeholders and defer remaining things for next cycle on security features blueprint . DONE only SECCOMP remains, Nicolas has it all in his head :-) . ACTION Nicolas to finish SECCOMP support * Arnd to send patches to fix all io.h copies . INPROGRESS thrown the old patches away and is working on a new version of the patches now; mostly fixing the code to use the correct pointer type all over the place, without awful casts; trying to fix code to use iomemory pointers * Nico to send feedback to jk on the DT ARM patches this week . INPROGRESS, Nicolas writing amendments to the patches and about to send them to Jeremy and Grant * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config . CO * Loïc to send out his notes on release process . DONE * Matt to file bugs and try the ARM kernel for both bugs . DONE * Arnd to file bug on SD card alignment . DONE * Arnd bought an Android tablet PC and looked at the kernel sources; this is for very old cores from Asian manufacturers * Arnd also worked a bit on BKL removal * Nicolas started work on the gdb vector page bug; patch he sent wasn't sufficient, since gdb is using /proc/*/mem as well; trying to fix this nicely * Shajul trying to boot devicetree on ST-E platform with an embedded platform; only has memory and cmdline in the devicetree and working on the clock * Dave has been mostly working on non-kernel stuff this week, such as building stuff with -Os * Jeremy worked on debug macros, rebasing them on a newer kernel; Russell requested a different strategy on merging them, should be ok for the beginning of the merge window * Jeremy will be away for about 3 weeks at the beginning of October * Jeremy thinks we should consider merging the common clock framework now, since discussion seems to have quieten down; should go via Russell's tree, his initial work to start with * Grant works on random platform-specific stuff, and notably OMAP; Grant is syncing with Richard on this work * Grant is also working on a lot of tools, compilers etc. for FPGA platforms notably == Activity reports == === Shaju Abraham === * Work on device tree support for V210 is progressing * Tested common clock API for the V210; works * Making a small DTS file for the V210 to test DeviceTree part === Matt Waddel === ==== this week ==== * validated new vexpress headless images * found bug in u-boot causing initrd problems * found problem with flash mtd mounting (thx lool and scottb) * several changes to linaro-media-create script for vexpress * closed outstanding linaro-media-create bugs assigned to me * qatracker deploy instructions * re-formated u-boot patches - will submit tomorrow ==== next week ==== * US holiday * push u-boot changes before merge window opens * bug fixing on vexpress - memory issue, initrd on command line * flash-kernel implementation * try Lorenzo's vexpress arm device-tree * Start mmc u-boot device driver === Arnd Bergmann === * debugged Versatile PCI with Peter Maydell * started review of ST-Ericsson BSP * mmio cleanup in arm tree * investigated Telechips BSP ==== Non-Linaro but noteworthy ==== * Open vSwitch discussion * cleanup of TTY layer * debugging of BKL removal fallout === Dave Martin === ==== arm-m-memory-footprint ==== * Ongoing discussion with upstream. ==== arm-m-debugging-with-oprofile ==== * See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608775 for detail on current status (still waiting for feedback from upstream developer for final patch) ==== Kernel ==== ===== arm-m-missing-security-features ===== * kees still working on SECCOMP support; ===== miscellaneous ===== * Investigation of Freescale bsp mostly done -- need to write up. * Retested omap3 / vexpress release candidates; reported some issues. * Tested amit's NEON conditional NEON en-/dis-ablement workaround for i.MX51. * UDS travel now booked ==== Plans ==== * Summarise -Os results * Test the linaro stable kernel tree on OMAP3/Beagle -- see whether the omapfb problems are now fixed. * Test omap/vexpress beta release candidates when they've been respun. * Follow up with jcrigby on how to enable building of a fixed linux-tools package for linaro. === John Rigby === ==== Kernel Packaging ==== * Put the ST-E kernel in its own tree on git.linaro.org and added packaging. * Got feedback on linux-linaro kernel, it needs to recommend uboot-mkimage. * Proposed two possible ways of doing per-flavour sources to Tim Gardner. He said they would probably work but said he didn't like the idea. ==== U-Boot ==== * Did a new U-Boot DevTree patch submission. No feedback yet. * Discussed unified U-Boot via email with Loic and Steve Sakoman. Steve is pretty skeptical. ==== Other ==== * Helped with testing release. First rc was bad because it had old kernel. ==== Next Week ==== * First monthly kernel build is due Wednesday. === Paul McKenney === ==== RCU Priority Boosting ==== * Implemented and tested RCU priority boosting changes to the rcutorture test suite. * The testing experience highlighted a hole in the design, which I am fixing. (I will need to priority-boost the RCU softirq, which will mean converting it to a kthread -- easy change.) * Started coding TINY_PREEMPT_RCU's priority boosting. ==== ARM Hardware ==== * Worked with IBM India to straighten out the process for receiving ARM development boards (they were applying processes appropriate for $1M servers to $200 development boards). * Received a Sheeva Plug, have not yet had time to play with it. === Nicolas Pitre === * Merged some fixes for ARM profiling and for the OMAP framebuffer in the linaro 2.6.35 stable kernel tree * Handling of patches for i.MX51 and CONFIG_NEON * Review of the DT patchset from gcl's git tree. Some style issues only so far. * Tested patch for bug 620611: turned out to be insufficient. investigation for a proper fix has led me deep down in the generic mm code. * Some minor progress on the SECCOMP patch. * Misc (meeting attendance, mailing list monitoring, etc.) -- Loïc Minier

16 years

[PATCH 1/3] PM / Runtime: Add runtime PM statistics (v3)

by yong.shen＠linaro.org

From: Arjan van de Ven <arjan(a)linux.intel.com> In order for PowerTOP to be able to report how well the new runtime PM is working for the various drivers, the kernel needs to export some basic statistics in sysfs. This patch adds two sysfs files in the runtime PM domain that expose the total time a device has been active, and the time a device has been suspended. With this PowerTOP can compute the activity percentage Active %age = 100 * (delta active) / (delta active + delta suspended) and present the information to the user. I've written the PowerTOP code (slated for version 1.12) already, and the output looks like this: Runtime Device Power Management statistics Active Device name 10.0% 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [version 2: fix stat update bugs noticed by Alan Stern] [version 3: rebase to -next and move the sysfs declaration] Signed-off-by: Arjan van de Ven <arjan(a)linux.intel.com> Signed-off-by: Rafael J. Wysocki <rjw(a)sisk.pl> --- drivers/base/power/runtime.c | 54 ++++++++++++++++++++++++++++++---- drivers/base/power/sysfs.c | 65 +++++++++++++++++++++++++++++++++++++++++- include/linux/pm.h | 6 ++++ 3 files changed, 117 insertions(+), 8 deletions(-) diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index b0ec0e9..b78c401 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -123,6 +123,45 @@ int pm_runtime_idle(struct device *dev) } EXPORT_SYMBOL_GPL(pm_runtime_idle); + +/** + * update_pm_runtime_accounting - Update the time accounting of power states + * @dev: Device to update the accounting for + * + * In order to be able to have time accounting of the various power states + * (as used by programs such as PowerTOP to show the effectiveness of runtime + * PM), we need to track the time spent in each state. + * update_pm_runtime_accounting must be called each time before the + * runtime_status field is updated, to account the time in the old state + * correctly. + */ +void update_pm_runtime_accounting(struct device *dev) +{ + unsigned long now = jiffies; + int delta; + + delta = now - dev->power.accounting_timestamp; + + if (delta < 0) + delta = 0; + + dev->power.accounting_timestamp = now; + + if (dev->power.disable_depth > 0) + return; + + if (dev->power.runtime_status == RPM_SUSPENDED) + dev->power.suspended_jiffies += delta; + else + dev->power.active_jiffies += delta; +} + +static void __update_runtime_status(struct device *dev, enum rpm_status status) +{ + update_pm_runtime_accounting(dev); + dev->power.runtime_status = status; +} + /** * __pm_runtime_suspend - Carry out run-time suspend of given device. * @dev: Device to suspend. @@ -197,7 +236,7 @@ int __pm_runtime_suspend(struct device *dev, bool from_wq) goto repeat; } - dev->power.runtime_status = RPM_SUSPENDING; + __update_runtime_status(dev, RPM_SUSPENDING); dev->power.deferred_resume = false; if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_suspend) { @@ -228,7 +267,7 @@ int __pm_runtime_suspend(struct device *dev, bool from_wq) } if (retval) { - dev->power.runtime_status = RPM_ACTIVE; + __update_runtime_status(dev, RPM_ACTIVE); if (retval == -EAGAIN || retval == -EBUSY) { if (dev->power.timer_expires == 0) notify = true; @@ -237,7 +276,7 @@ int __pm_runtime_suspend(struct device *dev, bool from_wq) pm_runtime_cancel_pending(dev); } } else { - dev->power.runtime_status = RPM_SUSPENDED; + __update_runtime_status(dev, RPM_SUSPENDED); pm_runtime_deactivate_timer(dev); if (dev->parent) { @@ -381,7 +420,7 @@ int __pm_runtime_resume(struct device *dev, bool from_wq) goto repeat; } - dev->power.runtime_status = RPM_RESUMING; + __update_runtime_status(dev, RPM_RESUMING); if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_resume) { spin_unlock_irq(&dev->power.lock); @@ -411,10 +450,10 @@ int __pm_runtime_resume(struct device *dev, bool from_wq) } if (retval) { - dev->power.runtime_status = RPM_SUSPENDED; + __update_runtime_status(dev, RPM_SUSPENDED); pm_runtime_cancel_pending(dev); } else { - dev->power.runtime_status = RPM_ACTIVE; + __update_runtime_status(dev, RPM_ACTIVE); if (parent) atomic_inc(&parent->power.child_count); } @@ -848,7 +887,7 @@ int __pm_runtime_set_status(struct device *dev, unsigned int status) } out_set: - dev->power.runtime_status = status; + __update_runtime_status(dev, status); dev->power.runtime_error = 0; out: spin_unlock_irqrestore(&dev->power.lock, flags); @@ -1077,6 +1116,7 @@ void pm_runtime_init(struct device *dev) dev->power.request_pending = false; dev->power.request = RPM_REQ_NONE; dev->power.deferred_resume = false; + dev->power.accounting_timestamp = jiffies; INIT_WORK(&dev->power.work, pm_runtime_work); dev->power.timer_expires = 0; diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c index a4c33bc..7ee064f 100644 --- a/drivers/base/power/sysfs.c +++ b/drivers/base/power/sysfs.c @@ -6,6 +6,7 @@ #include <linux/string.h> #include <linux/pm_runtime.h> #include <asm/atomic.h> +#include <linux/jiffies.h> #include "power.h" /* @@ -108,6 +109,66 @@ static ssize_t control_store(struct device * dev, struct device_attribute *attr, } static DEVICE_ATTR(control, 0644, control_show, control_store); + +static ssize_t rtpm_active_time_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + int ret; + spin_lock_irq(&dev->power.lock); + update_pm_runtime_accounting(dev); + ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies)); + spin_unlock_irq(&dev->power.lock); + return ret; +} + +static DEVICE_ATTR(runtime_active_time, 0444, rtpm_active_time_show, NULL); + +static ssize_t rtpm_suspended_time_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + int ret; + spin_lock_irq(&dev->power.lock); + update_pm_runtime_accounting(dev); + ret = sprintf(buf, "%i\n", + jiffies_to_msecs(dev->power.suspended_jiffies)); + spin_unlock_irq(&dev->power.lock); + return ret; +} + +static DEVICE_ATTR(runtime_suspended_time, 0444, rtpm_suspended_time_show, NULL); + +static ssize_t rtpm_status_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + const char *p; + + if (dev->power.runtime_error) { + p = "error\n"; + } else if (dev->power.disable_depth) { + p = "unsupported\n"; + } else { + switch (dev->power.runtime_status) { + case RPM_SUSPENDED: + p = "suspended\n"; + break; + case RPM_SUSPENDING: + p = "suspending\n"; + break; + case RPM_RESUMING: + p = "resuming\n"; + break; + case RPM_ACTIVE: + p = "active\n"; + break; + default: + return -EIO; + } + } + return sprintf(buf, p); +} + +static DEVICE_ATTR(runtime_status, 0444, rtpm_status_show, NULL); +>>>>>>> 8d4b9d1... PM / Runtime: Add runtime PM statistics (v3):drivers/base/power/sysfs.c #endif static ssize_t @@ -228,6 +289,9 @@ static DEVICE_ATTR(async, 0644, async_show, async_store); static struct attribute * power_attrs[] = { #ifdef CONFIG_PM_RUNTIME &dev_attr_control.attr, + &dev_attr_runtime_status.attr, + &dev_attr_runtime_suspended_time.attr, + &dev_attr_runtime_active_time.attr, #endif &dev_attr_wakeup.attr, #ifdef CONFIG_PM_ADVANCED_DEBUG @@ -235,7 +299,6 @@ static struct attribute * power_attrs[] = { #ifdef CONFIG_PM_RUNTIME &dev_attr_runtime_usage.attr, &dev_attr_runtime_active_kids.attr, - &dev_attr_runtime_status.attr, &dev_attr_runtime_enabled.attr, #endif #endif diff --git a/include/linux/pm.h b/include/linux/pm.h index 8e258c7..dca597f 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -476,9 +476,15 @@ struct dev_pm_info { enum rpm_request request; enum rpm_status runtime_status; int runtime_error; + unsigned long active_jiffies; + unsigned long suspended_jiffies; + unsigned long accounting_timestamp; #endif }; +extern void update_pm_runtime_accounting(struct device *dev); + + /* * The PM_EVENT_ messages are also used by drivers implementing the legacy * suspend framework, based on the ->suspend() and ->resume() callbacks common -- 1.6.3.3

16 years

armel cross toolchain packages available in PPA

by Marcin Juszkiewicz

I would like to announce that my work on armel cross toolchain got to the very nice point - all packages are available from PPA. What does it mean to you? 1. no "are you sure to install those unverified packages" messages from APT 2. ability to easily rebuild toolchain on own machines So if you used my repository from people.canonical.com then please switch to PPA one: add-apt-repository ppa:hrw/armel-cross-compilers Old repository will be available for some time but will not get any updates. Next step: merging those packages into Maverick release. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

16 years

linux-meta-linaro pull request

by John Rigby

The following changes since commit c1d6a8296b6d3fe47938ae3ff22ecaa8cded9835: John Rigby (1): LINARO: Linaro-2.6.35-1004.9 are available in the git repository at: git://git.linaro.org/ubuntu/linux-meta-linaro.git master John Rigby (1): LINARO: Linaro-2.6.35.1005.10 meta-source/debian/changelog | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)

16 years

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev September 2010