- linaro-kernel - lists.linaro.org

by John Stultz

=== Highlights === * Reworked the mmc wakelocks patch to use wakeup sources and sent to google developers for review prior to sending to lkml * After getting negative feedback on my interval tree implementation, I'm reworking my volatile ranges patch set to not introduce a new base type and just use rbtrees internally. * Submitted a number of changes in timekeeping for 3.6 to Thomas for -tip * Wrote first draft on android usptreaming update for member newsletter * Resent out the ETM patches for inclusion * Ran bi-weekly android-usptreaming subteam call (over irc since mumble was having problems) * Merged fix from Tushar into linaro-android-3.5-jstultz-rebase tree === Plans === * Continue reworking volatile range code & resubmit for comment * Submit mmc wakeup source patch to lkml * Ping Russel on ETM * Finish member newsletter update === Issues === NA

13 years, 5 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-06-18 to 2012-06-22

by Rajanikanth HV

====Activity Summary==== - Completed DT binding for ab8500-btemp . Pending: Code Review/Rework and Documentation . Added a macro to traverse phandle list in a property . Unit/Driver level test succeeds in fetching and populating DT information - Started DT bindings for ab8500 Fuel Guage driver as ab8500-btemp driver expects "battery resistance" platform information from ab8500-fg without which ab8500 probe shall not be complete as per the present sequence - Support for Raj on mmap freezing issue: - Observed that iterative vmalloc and vfree is causing kernel to free on fully loaded/android case, however the said issue is not observed in LBP (non-android/ubuntu) build. Raj has created ticket on igloo kernel community - Looking into L2Cache settings highlighted by mathieu, trying to seek information on offset 0x7CC used and necessity of using cache lockdown (0x900/4) Ref: cleanup_before_linux() =====Plan==== - Complete DT binding for ab8500-fg driver - test ab8500-btemp - Documentation - Review and rework ====issues==== NA Thanks, Rajanikanth

13 years, 5 months

1
0
0 0

Location of specific kernel sourcecode?

by RabidCicada

Hello all, Short: Please point me to the kernel sourcecode repo and checkout for the resulting image created for the pandaboard by the following files: hwpack_linaro-lt-panda-x11-base_20120505-32_armhf_supported.tar.gz linaro-precise-ubuntu-desktop-20120426-119.tar.gz uname -a gives "Linux linaro-ubuntu-desktop 3.3.1-38-linaro-lt-omap #38~lt~ci~00000000000001+1336186099~4fa4ad78-Ubuntu" Long: New to Linaro and trying to make some GPIOKey's mods to the kernel to support a pushbutton on the pandaboard. I'm relatively new to modding the linux kernel, and just picking up git for the first time. I am completely unfamiliar with the linaro way of doing things and naming scheme and can't figure out what would be the kernel source for this build. I found this http://ask.linaro.org/questions/586/where-are-kernel-sources-for-panda-boar… no answer and I managed to check out the root kernel source from git.linaro.org/landing-teams/leb/ti/kernel.git but I can't find what would likely be the kernel source for this particular build. I would really appreciate if someone would point me to the sourcecode for the kernel in this combination of linaro-media-create files: hwpack_linaro-lt-panda-x11-base_20120505-32_armhf_supported.tar.gz linaro-precise-ubuntu-desktop-20120426-119.tar.gz I found the manifest in the hwpack tarfile and I believe I'm looking for a 3.3 kernel. If anyone wants to explain a little about the Linaro-Way or naming schemes that would be helpful also. -- "Ambush!?....I just ambushed you with a cup of coffee" -CIA agent (RONIN)

13 years, 5 months

3
6
0 0

[PATCH 0/7] pstore/ram: Early registration and configurable ECC buffers size

by Anton Vorontsov

Hi all, Here are some more updates for the pstore/ram: it is implementation of Colin Cross's and Arve Hjønnevåg's suggestions, i.e. early probing and configurable ECC size. The last one needed quite a bit of cleanups in the core code, though. Thanks, --- fs/pstore/ram.c | 77 ++++++++++++++++++++++---------------------- fs/pstore/ram_core.c | 65 ++++++++++++++++++++----------------- include/linux/pstore_ram.h | 11 +++---- 3 files changed, 79 insertions(+), 74 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

3
12
0 0

[ACTIVITY] (Anton Vorontsov) 2012-06-04 - 2012-06-15

by Anton Vorontsov

== Highlights == * Started work on FIQ debugger. There are four parts: FIQ handling, serial port handling, KGDB support and "debug shell" implementation. The latter is mostly what adds LOC count, and this is definitely what should be merged with KDB support, since we really don't want have multiple debug shells implementations in the kernel (there are three already: PowerPC-specific xmon (predates KDB), generic KDB and now ARM-specific FIQ debugger shell. So, the work involves refactoring the FIQ debugger so that it would play nicely with KDB (and adjusting KDB when needed, i.e. preserving all the FIQ debugger's features). * Modified pstore/ftrace so that it is now it is an option to the stock function tracer. Folks want to make tracing data kernel version specific, which is a good idea. It is easy to implement it, but I will wait a bit before resending the set again. * Finally forced myself to divert attention from FIQ stuff and write commit messages for the bunch of pstore/ram patches that were ready approximately a week ago: configurable ECC buffers size, early probe and some error-handling fixes. These have now been sent out. * Apart from the latest discussion on lkml, no updates on vmevent. Minchan said he would present his approach soon, but he didn't share much details on it. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

1
0
0 0

[Activity] (Omar Ramirez) Jun 11 - Jun 17

by Omar Ramirez Luna

=== omarrmz === === Highlights === * ISP testing environment set up. - Streaming failures associated with the commands and binaries used, unable to test streaming however initialization of isp module looks good. * Testing iommu hwmod and runtime, along with the reset handling changes, on rpmsg branches and master linux-omap - Boards used OMAP3 (beagle), OMAP4 (panda). * Reset handling API proposal completed and submitted to LO. - Cleanup finished, split original series as these patches are only related to hwmod. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70443.html * Iommu hwmod and runtime conversion completed and submitted to LO. - Rebase and cleanup done. - Split this series from DT since there are too many patches on hwmod that need to be accepted first. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html * Rebased rpmsg to 3.5-rc2 - There seem to be conflicts with the carveouts, need to investigate. === Plans === * Investigate carveout issues on 3.5-rc2 * Work on IOMMU DT, this patches required as prerequisite the hwmod reset handling and the iommu hwmod conversion + runtime, that were recently submitted. Regards, Omar

13 years, 6 months

1
0
0 0

[ACTIVITY] (Shawn Guo) Week of Jun 11

by Shawn Guo

=== Highlight === * Sent a series to enable SPARSE_IRQ support for imx to make the platform ready for multi-platform build. * Sent a RFC patch adding clock lookup from device tree based on Rob Herring's DT clock bindings (v3) for discussing a couple of problems I have seen with using the binding on imx clock tree. * Reviewed and tested "Per sub-architecture SMP operations" series from Marc Zyngier on imx6q. * Reviewed a bunch of mxs DT patches from Marek Vasut and Fabio Estevam. -- Regards, Shawn

13 years, 6 months

1
0
0 0

[ACTIVITY] (Dong Aisheng) June-11-June-15

by Dong Aisheng

=== Highlights === * reviewed some pinctrl-mxs patches from Devendra Naga. * reviewed Russell King's "RFC: changing DMA slave configuration API". Gave suggestion on supporting peripheral to peripheral dma transfer since IMX SDMA supports such type of transfer. * reviewed Shawn's big patch series(16 patches) of adding irqdomain and sparse irq support for IMX platforms. Acked most of them, also gave some comments and suggestions on the rest. Some got response while somes still not. === Plan === * Improving pinctrl gpio common binding according to Grant's suggestion Did not have too much time to do it last week, will do it this week. * Reviewing irq domain support and sparse irq support for imx. Continue to track the patches if any update. * imx-sdma clean up. Found some issues, will do clean up later.

13 years, 6 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-06-04 to 2012-06-15

by Rajanikanth HV

====Activity Summary==== - Prepared DT file for ab8500 btemp and dependents, found btemp and bat_type structure are quite vast, comprises charging parameters, fuel gauge etc., [Observed scope for optimization] - Implemented review comments from Lee Jones - Fixed few kernel panic and phandle issues in btemp_probe routine. =====plan==== - fillup battery mgmt data and battery type structure to complete btemp_probe - testing - Documentation ====issues==== NA Thanks, Rajanikanth

13 years, 6 months

1
0
0 0

[ACTIVITY] (Venkatraman S) 2012 June 11-15

by Venkatraman S

=== Venkatraman S <svenkatr> === === Highlights === * Reviewed & tested Power Off Notify with eMMC4.4 * Review the updated packed CMD implementation and testing * Review the updated BKOPS feature patch (v9) from Samsung * Review the test I/O scheduler proposal from codeaurora * Prepared eMMC and UFS feature branches for Linaro monthly release. * Reviewed work Items and future work proposals with Saugata and new assignee. * Internal review & briefing on various storage topics === Plans === * On internal training on Monday, 18th June * eMMC4.5 JIG board stopped working after I returned from HK - need to investigate * continue reviewing on eMMC features and follow up to get it merged for 3.6 * Testing BKOPS performance with conditions on prototype devices * Repost HPI after fixing a DMA unmapping (post req) bug

13 years, 6 months

1
0
0 0

[ACTIVITY] (John Stultz) June 11-15

by John Stultz

=== Highlights === * Implemented a first pass iteration at pushing the volatile range eviction code deeper into the VM * Sent it out reworked volatile range code to lkml, but got very little feedback. * Sent out the Android ETM driver changes to lkml for review and inclusion. Also got very little feedback (is everyone on vacation!?) * Sent out weekly android upstreaming status mail * Got pinged by Dave Jones to make sure relavant leap-second fixes land in -stable, sent patch out. * Migrated to a new build box as well as a new backup server. Learned some additional tricks for fixing accidentally corrupted git repos. === Plans === * Try to implement a middle ground approach to improving volatile purging without using a shrinker. * Resend ETM driver for inclusion === Issues === NA

13 years, 6 months

1
0
0 0

[PATCH v2 0/6] Function tracing support for pstore

by Anton Vorontsov

Hi all, In v2: - Do not introduce a separate 'persistent' tracer, but introduce an option to the existing 'function' tracer. Rationale for this patch set: With this support kernel can save functions call chain log into a persistent ram buffer that can be decoded and dumped after reboot through pstore filesystem. It can be used to determine what function was last called before a hang or an unexpected reset (caused by, for example, a buggy driver that abuses HW). Here's a "nano howto", to get the idea: # mount -t debugfs debugfs /sys/kernel/debug/ # cd /sys/kernel/debug/tracing # echo function > current_tracer # echo 1 > options/func_pstore # reboot -f [...] # mount -t pstore pstore /mnt/ # tail /mnt/ftrace-ramoops 0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0 0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0 0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90 0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90 0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40 0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0 0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0 0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0 0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40 0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20 Mostly the code comes from trace_persistent.c driver found in the Android git tree, written by Colin Cross <ccross(a)android.com> (according to sign-off history). I reworked the driver a little bit, and ported it to pstore subsystem. --- Documentation/ramoops.txt | 25 +++++++++ fs/pstore/Kconfig | 12 +++++ fs/pstore/Makefile | 6 +++ fs/pstore/ftrace.c | 35 +++++++++++++ fs/pstore/inode.c | 111 ++++++++++++++++++++++++++++++++++++++-- fs/pstore/internal.h | 49 ++++++++++++++++++ fs/pstore/platform.c | 12 ++++- fs/pstore/ram.c | 54 ++++++++++++++----- include/linux/pstore.h | 13 +++++ include/linux/pstore_ram.h | 1 + kernel/trace/trace.c | 7 +-- kernel/trace/trace_functions.c | 25 +++++++-- 12 files changed, 325 insertions(+), 25 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

5
18
0 0

[ACTIVITY] (Linus Walleij) 2012-06-08 - 2012-06-15

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Send a pull request to Linus Torvalds for pin control updates, it was duly pulled in for v3.5-rc3. * Sent of a pull request to the ARM SoC maintainers for a bunch of Nomadik updates. * Spend some time funneling back the pinctrl updates and ux500 patches for pin control to ST-Ericssons internal development track. Also synchronized the PL022 SPI driver in both directions, submitting patches externally and internally. This will take some more time still. * Discussed and iterated device tree patches for Nomadik I2C. Also ACKed Alessandros patches to move the controller to the AMBA bus (so it can be reused in ST Microelectronics products). * Poked Greg about the UART regression on Ux500 and he picked up the patch to the TTY tree. * Sent off some clock modernization patches for the ARM Integrator, iterated with Mike Turquette. * Had extensive discussions on internal ST-Ericsson matters and internal code review cutting out a share of my working hours. === Plans === * Vacation: 23 june -> 30 june 9 july -> 3 august (preliminary) (now also reflected in Linaro leaves) * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. === Issues === * N/A Thanks, Linus Walleij

13 years, 6 months

1
0
0 0

[PATCH v5 0/11] Merge ram_console into pstore

by Anton Vorontsov

Hi all, And another respin, v5 this time: - Split out fixes into a separate series; - Added proper spinlock protection to the pstore/console interface (the bug I found when was adding ftrace interface); - And as I'm about to add ftrace support to pstore, to not touch the same lines of code twice, I reworked 'Factor ramoops_get_dump_prz() out of ramoops_pstore_read()' patch into 'Factor ramoops_get_next_prz() out of ramoops_pstore_read()'. This is just a more generic interface that will work for both console and ftrace przs. Since the patch changed drastically, it lost Kees' ack, so it needs a re-ack. - The same as above happened w/ 'Introduce ramoops_context.max_dump_count' patch, it turned into 'Give proper names to dump-related variables', it also needs a re-ack. - If anyone is willing to try the patches, for convenience they are now available in the git repository: git://git.infradead.org/users/cbou/linux-pstore.git or gitweb: http://git.infradead.org/users/cbou/linux-pstore.git In v4: - Per Kees Cook's comments, the patches no longer remove an automatic updates feature, but instead make the it configurable; plus disable it by default (in a separate patch); - Fixed some bugs noticed by Colin Cross; - Documented new continuous ramoops-console log behaviour (also noticed by Colin Cross). In v3: - Rebased on top of current staging-next; - The series are getting bigger. This is partly because we now support different persistent zone sizes for oops records and console log, per Colin Cross' request. And I believe the code is now more manageable for further enhancements (e.g. if we'd want to add other message types, e.g. tracing); - Addressed Kees Cook's comments on the unlinking matters; - Removed automatic updates support. Please see the last patch description for rationale; - A new fixup for pstore/inode, just getting rid of a sparse warning. In v2: - Updated documentation per Colin Cross' comments; - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook); - Fixed large writes handling in pstore_console_write(), i.e. when log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook. And a boilerplate for the series: Currently pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE, plus make pstore/ram.c handle the new messages. The old ram_console driver is removed. This might probably cause some pain for out-of-tree code, as it would need to be adjusted... but "no pain, no gain"? :-) Though, if there's some serious resistance, we can probably postpone the last two patches. Thanks! --- Documentation/ramoops.txt | 14 ++ drivers/staging/android/Kconfig | 5 - drivers/staging/android/Makefile | 1 - drivers/staging/android/ram_console.c | 179 ------------------------ fs/pstore/Kconfig | 7 + fs/pstore/inode.c | 3 + fs/pstore/platform.c | 54 +++++++- fs/pstore/ram.c | 246 ++++++++++++++++++++++++--------- fs/pstore/ram_core.c | 81 +---------- include/linux/pstore.h | 1 + include/linux/pstore_ram.h | 20 +-- 11 files changed, 261 insertions(+), 350 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

6
20
0 0

[PATCH 0/5] Some pstore/ramoops fixes

by Anton Vorontsov

Hi Greg, In the light of Linus' response, and I said this to Colin already, I'll just zap a prz at boot time for pstore/console interface, which means that nowadays there shouldn't be any objections to this bunch of fixes. These are valid fixes for v3.5, they restore old pstore's behavior nuances, which I changed accidentaly. Except for the last patch, which is just a fix I happened to make when I got bored of the warning. :-) Not a regression fix, though. Thanks, --- fs/pstore/inode.c | 2 +- fs/pstore/ram.c | 3 +++ fs/pstore/ram_core.c | 27 +++++++++++++++++---------- include/linux/pstore_ram.h | 2 ++ 4 files changed, 23 insertions(+), 11 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

3
8
0 0

[PATCH 0/3] vmevent: Implement 'low memory' attribute

by Anton Vorontsov

Hi all, Accounting only free pages is very inaccurate for low memory handling, so we have to be smarter here. The patch set implements a new attribute, which is blended from various memory statistics. Vmevent can't expose all the kernel internals to the userland, as it would make internal Linux MM representation tied to the ABI. So the ABI itself was made very simple: just number of pages before we consider that we're low on memory, and the kernel takes care of the rest. Thanks, -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

7
93
0 0

[ACTIVITY] (John Stultz) June 4 - June 8

by John Stultz

=== Highlights === * Volatile Range work was covered by LWN: https://lwn.net/Articles/500382/ * Found a few bugs in my current Volatile range work & fixed them. * Got some complex feedback on how volatile range purging should connect into the VM core. Mostly objections to using the shrinkers to trigger purging. Unfortunately this is a fairly complex issue and my VM-fu isn't quite at the level it needs to be to have proper conversations on it. * Spent time looking at the VM code trying to better understand all the moving parts. * Synced with Anton for the Android biweekly call. * Talked w/ MathieuP about Android Upstreaming work items that could use some extra hands. * Per LinusW's suggestion, pinged ETM maintainer on the status of the Android ETM patches. * Synced w/ Andrey about 12.06 plans and updated and pushed out my linaro-android-3.5-jstultz-rebase branch * Got some testing on the new wakelock infrastructure. Looks pretty good! * Updated the linaro-config branch to 3.5 and added Tixy's changes. * Discussed config fragment planning and Tixy taking over the linaro-config tree. === Plans === * More reading the VM code. * Take a first shot at reworking the VM core to handle volatile ranges. === Issues === * VM code makes my brain hurt

13 years, 6 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-05-26 - 2012-06-08

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Attended Linaro connect, ran a presentation, planned... * Spend some time funneling back the pinctrl updates and ux500 patches for pin control to ST-Ericssons internal development track. This will take some more time still. * Reviewed, acked/nacked discussed etc a hoarde of device tree patches from Lee during connect. I screwed up Lee's patches by applying them out-of-order, lesson learned: let Lee send his own pull request instead of picking and choosing. * Reviewed and tested a PL08x DMA patch bomb including the split into virtual channels from Russell King. This is real nice work by Russell, done as part of his OMAP DMA engine transfer assignment. * Reviewed a bunch of incoming pin control patches. * Sent an update converting Nomadik to use dynamic device allocation, use the common clock framework, and added support for PL031 RTC and MMC/SD-card to it. * Authored a patch to transfer Nomadik STn8815 to use pin control so we can clean up the implementation. * Reviewed Alessandro Rubini's patches for the Nomadik/Ux500 i2c controller, tested it, found some bugs and sent solutions back to Alessandro. * Had extensive discussions on internal ST-Ericsson matters cutting out a share of my working hours. === Plans === * Send pull request for Nomadik changes pt 1. * Vacation: 23 june -> 30 june 9 july -> 3 august (preliminary) * Check that Greg picks up the PL011 patch solving a regression on ux500. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... like - the HWMON stuff. === Issues === * N/A Thanks, Linus Walleij

13 years, 6 months

1
0
0 0

[ACTIVITY] (Dong Aisheng) June-4-June-8

by Dong Aisheng

=== Highlights === * reviewed some pinctrl-imx fix patches from Devendra Naga * sent out a pinctrl-imx fix patch * investigated adding sparse irq and irq domain support for imx We planned to add irq domain support first and sparse irq depends on it. * As discussed with Linus and Grant on implementing pinctrl gpio common binding in Linaro Connect, i spent some time, but not had too much this week, on trying Grant's suggestion to improve my patch series, still not done. === Plan === * trying Grant's suggestion on improving my pinctrl gpio common binding patches then discuss it with Linus and Grant based on the trying result. * adding irq domain support and sparse irq support for imx

13 years, 6 months

1
0
0 0

[PATCH 0/5] Function tracing support for pstore

by Anton Vorontsov

Hi all, With this support kernel can save functions call chain log into a persistent ram buffer that can be decoded and dumped after reboot through pstore filesystem. It can be used to determine what function was last called before a hang or an unexpected reset (caused by, for example, a buggy driver that abuses HW). Here's a "nano howto", to get the idea: # mount -t debugfs debugfs /sys/kernel/debug/ # cd /sys/kernel/debug/tracing # echo persistent > current_tracer # reboot -f [...] # mount -t pstore pstore /mnt/ # tail /mnt/ftrace-ramoops 0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0 0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0 0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90 0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90 0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40 0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0 0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0 0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0 0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40 0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20 Mostly the code comes from trace_persistent.c driver found in the Android git tree, written by Colin Cross <ccross(a)android.com> (according to sign-off history). I reworked the driver a little bit, and ported it to pstore subsystem. The patches depend on a pile of other pstore-related work, so if anyone is willing to try the patches, they would rather grab the whole git tree: git://git.infradead.org/users/cbou/linux-pstore.git or gitweb: http://git.infradead.org/users/cbou/linux-pstore.git Note that so far I've tried to not change the original idea, but if we consider inclusion, there are some open questions: 1. Should we merge persistent tracer with normal function tracer, i.e. add some flag that makes function tracer to duplicate the events into pstore (via a callback to pstore)? 2. If we keep the two separate, should the code live in fs/pstore or kernel/trace?.. I can see valid points for both approaches. Thanks, --- Documentation/ramoops.txt | 24 +++++++++ fs/pstore/Kconfig | 12 +++++ fs/pstore/Makefile | 6 +++ fs/pstore/ftrace.c | 122 ++++++++++++++++++++++++++++++++++++++++++++ fs/pstore/inode.c | 111 ++++++++++++++++++++++++++++++++++++++-- fs/pstore/internal.h | 49 ++++++++++++++++++ fs/pstore/platform.c | 13 ++++- fs/pstore/ram.c | 54 +++++++++++++++----- include/linux/pstore.h | 5 ++ include/linux/pstore_ram.h | 1 + kernel/trace/trace.c | 7 +-- 11 files changed, 384 insertions(+), 20 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

5
10
0 0

Fwd: [lca-announce] linux.conf.au 2013: Call For Proposals (closes July 6)

by Deepak Saxena

FYI... ---------- Forwarded message ---------- From: linux.conf.au Announcements <lca-announce(a)lists.linux.org.au> Date: 7 June 2012 07:50 Subject: [lca-announce] linux.conf.au 2013: Call For Proposals (closes July 6) To: lca-announce(a)lists.linux.org.au === linux.conf.au Call For Proposals === We are pleased to announce that the Call for Proposals for linux.conf.au 2013 is now open! The conference will showcase the best of open source and community-driven software and hardware. It will be held in Canberra at the Australian National University from Monday 28 January to Saturday 2 February, 2013, and provides a great opportunity for open source developers, users, hackers, and makers to share their ideas and further improve their projects. === Important Dates === * Call for proposals opens: 1 June 2012 * Call for proposals closes: 6 July 2012 * Email notifications from papers committee: 28 August 2012 * Early Bird registrations open: 1 October 2012 * Conference dates: Monday 28 January to Saturday 2 February 2013 === Information on Proposals === The linux.conf.au 2013 papers committee is looking for a broad range of proposals, and will consider submissions on anything from programming and software, to desktop, userspace, community, government, and education. There is only one rule: _Your proposal must be related to open source_ This year, the papers committee is going to be focused on deep technical content, and things we think are going to really matter in the future -- that might range from freedom and privacy to open source cloud systems or to energy efficient server farms of the future. However, the conference is to a large extent what the speakers make it -- if we receive many excellent submissions on a topic, then it’s sure to be represented at the conference. Here’s a few ideas to get you started: * Kernel and core systems: file systems, embedded devices * Networking: peer to peer networking, or tuning a TCP/IP stack * Desktop: office and productivity applications, peripherals, support * Mobile: kernel, applications, programming, challenges * Servers: clusters and supercomputers, databases and cloud computing * Embedded systems: constraints in storage/memory, real-time aspects, open hardware * Virtualisation: benefits, challenges, management, kernel and application support * Systems administration: maintaining large numbers of machines, disaster recovery * Security: application security, network security, cryptography, malware, viruses * Programming: programming languages, software engineering practices, testing, continuous integration/deployment, different development methodologies * Modern web technologies: Open source web browsers, HTML5, CSS3, JavaScript, web apps, accessibility * Audio and video: video editing, VoIP, WebRTC, video player development * Free software and free culture: licensing and Free and Open approaches outside software * Free software use: home, IT, education, manufacturing, research, government applications LCA is known for presentations and tutorials that are strongly technical in nature, but proposals for presentations on other aspects of free software and open culture, such as educational and cultural applications of open source, are welcome. === Code of Conduct === linux.conf.au welcomes first-time and seasoned speakers from all free and open communities - people of all ages, genders, nationalities, ethnicities, backgrounds, religions, abilities, and walks of life. We respect and encourage diversity at our conference. By agreeing to present at or attend the conference, you are agreeing to abide by the terms and conditions (http://lca2013.linux.org.au/cor/terms_and_conditions). We expect all speakers and delegates to have read and understood our Code of Conduct (http://lca2013.linux.org.au/cor/code_of_conduct). === Format === This year, there are three different ways that you can present your content: * Presentations * Tutorials * Miniconferences _Presentations_ Presentations are 40 minute slots that are generally presented in lecture format. These form the bulk of the available conference slots. _Tutorials_ Tutorials are 90 minutes that are generally presented in a classroom format. They should be interactive or hands-on in nature. Tutorials are expected to have a specific learning outcome for attendees. _Miniconferences_ Miniconfs are day-long sessions on a specific topic. A separate CFP process will be used to propose and select miniconfs, and will be announced publicly soon. For more information on miniconfs, see: http://lca2013.linux.org.au/miniconf-cfp === Speaker Information === In recognition of the value that speakers bring to our conference, once a proposal is accepted a speaker is entitled to: * Free registration, which holds all of the benefits of a Professional Delegate Ticket * Exclusive tickets to the Speakers' Dinner for the speaker and their immediate family * One free family ticket to the Partners' Programme If your proposal includes more than one speaker, these additional speakers are not entitled to free registration or to any extra benefits. linux.conf.au does not and will not pay speakers to present at the conference. linux.conf.au is able to provide limited financial assistance for some speakers, for instance, where the cost of flights or accommodation might prohibit a speaker from attending. Please note, however, that there is a limited budget for travel assistance and that asking for assistance could affect your chances of acceptance. === Recording and Licensing === To increase the number of people that can view your presentation, linux.conf.au might record your talk and make it publicly available after the event. When submitting your proposal you will be asked to release materials relating to your presentation under a Creative Commons ShareAlike License. Additionally, if you are discussing software in your presentation, you must ensure the software has an appropriate open licence. For more information, see: http://lca2013.linux.org.au/cfp === About Linux Australia === Linux Australia is the peak body for open source communities around Australia, and as such represents approximately 3500 Free and Open Source users and developers. Linux Australia supports the organisation of this international Free Software conference in a different Australasian city each year. For more information about Linux Australia see: http://www.linux.org.au/ === Papers Enquiries === linux.conf.au 2013 Papers Committee Email: papers-chair at lca2013.linux.org.au _______________________________________________ lca-announce mailing list lca-announce(a)lists.linux.org.au http://lists.linux.org.au/listinfo/lca-announce

13 years, 6 months

1
0
0 0

[PATCH 0/11] Merge ramoops and persistent_ram, generic pstore RAM backend

by Anton Vorontsov

Hi all, There are currently two competing debug facilities to store kernel messages in a persistent storage: a generic pstore and Google's persistent_ram. Not so long ago (https://lkml.org/lkml/2012/3/8/252), it was decided that we should fix this situation. Recently ramoops has switched to pstore, which basically means that it became a RAM backend for the pstore framework. persistent_ram+ram_console and ramoops+pstore have almost the same features, except: 1. Ramoops doesn't support ECC. Having ECC is useful when a hardware reset was used to bring the machine back to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat corrupt, but usually it is restorable. 2. Pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write a reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. These patches solve the first issue, plus move things to their proper places. Patches that will fix the second issue are pending. Thanks, --- drivers/char/Kconfig | 9 - drivers/char/Makefile | 1 - drivers/char/ramoops.c | 362 -------------------- drivers/staging/android/Kconfig | 10 +- drivers/staging/android/persistent_ram.c | 473 -------------------------- drivers/staging/android/persistent_ram.h | 78 ----- drivers/staging/android/ram_console.c | 2 +- fs/pstore/Kconfig | 12 + fs/pstore/Makefile | 1 + fs/pstore/ram.c | 384 ++++++++++++++++++++++ fs/pstore/ram_core.c | 530 ++++++++++++++++++++++++++++++ include/linux/pstore_ram.h | 99 ++++++ include/linux/ramoops.h | 17 - 13 files changed, 1028 insertions(+), 950 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

8
35
0 0

[ACTIVITY] (Anton Vorontsov) 2012-05-21 - 2012-06-01

by Anton Vorontsov

== Highlights == * Sent v5 of pstore/console patch set, so far it didn't receive any objections. Perhaps need to ping Greg, as the merge window is now closed; * Finished and sent out pstore/ftrace support; it got a preliminary thumbs up from Steven. Will need to merge the support to the generic function tracer, turning persistent storage into a flag. * Discussed various approaches to make continuous console logging in pstore. And as a part of it tried to make linux_banner printing somewhat more consistent. But folks did not like it, so in the end we'll have just one console log buffer, as it was with ram_console; * Restarted work on vmevents, but got unflattering comments from KOSAKI, plus Minchan started to doubt about the notifiers in general. There is some blowing hot and cold started again. == Plans == * Repost pstore/ftrace support with Steven Rostedt comments fixed. * Move pstore registration earlier, so that we can record early oopses. Suggested by Colin Cross. * Make pstore ecc settings configurable, i.e. address Arve Hjønnevåg's "nice to have" comment on pstore; * I plan to finish all the major pstore items this week, and thus will have to pick a new task; * See how vmevents discussion turns out. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

1
0
0 0

omap2plus kernel CI hwpacks fails to boot

by Deepti Kalakeri

Hello, Its been close to a month now that the kernel CI hwpacks built on ci.linaro.org with default omap2plus defconfigs (available in the linux-arm-soc, linux-next, linux-linaro, linux) are failing to boot on the boards. Here is an example hwpack built using the linux-linaro tree with omap2plus defconfig on ci.linaro.org which is failing to boot, in case you want to try to test it. http://snapshots.linaro.org/kernel-h wpack/linux-linaro-tracking/linux-linaro-tracking_panda-omap2plus/hwpack_linaro-lt-panda_20120509-0641_b64_armel_supported.tar.gz<http://snapshots.linaro.org/kernel-hwpack/linux-linaro-tracking/linux-linar…> I was able to fix the above boot problem of the CI kernel hwpacks built with omap2plus defconfig by adding the options similar to the ones available in (linux-linaro tree) default omap4 defconfig on top of the default omap2plus defconfig options. Here is the list of the config options which I added http://paste.ubuntu.com/977642/ along with the omap2plus defconfig to make it work. Can someone help me with the basic omap2plus defconfig options that will be required to boot the hwpack on the board. Does anyone care of kernel builds for linux-arm-soc, linux-next, linux-linaro, linux tree using omap2plus defconfigs ? Apart from this, there are build failures with the linux-next trees failing since last 20 days. https://ci.linaro.org/jenkins/view/Linux%20%28next%29/ lists such failing build jobs. For example the following job fails https://ci.linaro.org/jenkins/view/Linux%20%28next%29/job/linux-next_panda-… . Can someone look at these linux-next build failures ? -- Thanks and Regards, Deepti Infrastructure Team Member, 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, 6 months

7
17
0 0

Still travelling...

by Deepak Saxena

This is in the leaves calendar but thought I'd let folks know that I'm off Monday (which is mostly over for me) and tomorrow while I explore Beijing and then off to Linuxcon Japan tue-friday. I'm taking a few days off and will be back home next Tuesday evening PST, back to work sometime on Wed. I'll be checking email the whole time between now and next wed. If you need me for something urgent, email me and then txt me (+15039578596) so I get to my email ASAP. Thanks, ~Deepak

13 years, 6 months

1
0
0 0

about unuseful information in each message

by Wang wenbing

Hi sir/mrs, why there is unuseful information like attachment in every message?It will disturb us to read whole message. Thanks

13 years, 6 months

2
1
0 0

[ACTIVITY] (John Stultz) May 29 - June 1

by John Stultz

=== Highlights === * Reworked the fallocate volatile code per feedback and sent out two iterations. * Remotely presented Android Upstreaming status at Connect. * Fixed a leapsecond bug that was reported and sent it in for 3.5 * Spent some time getting my timekeeping queue for 3.6 in order * Sent out the Android Upstreaming biweekly team email === Plans === * Continue fallocate volatile discussion and code iterations. * Hopefully get a fix for the panda HDMI issue that's blocking my testing of upstreamed Android work that landed in 3.5 * Dig in on some of the items LinusW suggested I look at during the Connect session. === Issues === NA

13 years, 6 months

1
0
0 0

Send linaro-kernel mailing list submissions

by Wang wenbing

Send linaro-kernel mailing list submissions

13 years, 6 months

1
0
0 0

[PATCH v3 0/9] Fixes for common mistakes w/ for_each_process and task->mm

by Anton Vorontsov

Hi all, This is another resend of several task->mm fixes, the bugs I found during LMK code audit. Architectures were traverse the tasklist in an unsafe manner, plus there are a few cases of unsafe access to task->mm in general. There were no objections on the previous resend, and the final words were somewhere along "the patches are fine" line. In v3: - Dropped a controversal 'Make find_lock_task_mm() sparse-aware' patch; - Reword arm and sh commit messages, per Oleg Nesterov's suggestions; - Added an optimization trick in clear_tasks_mm_cpumask(): take only the rcu read lock, no need for the whole tasklist_lock. Suggested by Peter Zijlstra. In v2: - introduced a small helper in cpu.c: most arches duplicate the same [buggy] code snippet, so it's better to fix it and move the logic into a common function. Thanks, -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

5
16
0 0

[kernel boot] - Failed to boot the kernel building by myself. Could you please help on it?

by Tim Jiang

Hi Experts, I am a newbie in Linaro development. The kernel built by myself can't boot up. Could you please help on it? Thanks a lot in advance. # Proglem: There was no any response after following logs: Starting kernel ... Uncompressing Linux... done, booting the kernel. *Followings are details:* # My setting: Development board - i.Mx53 QSB Host PC - Ubuntu 10.04 x64 GCC for build linaro kernel - version is 4.6.2 Create a micro-SD card with linaro Nano 12.02. I used, mx53loco-nano.img.gz<http://releases.linaro.org/12.02/ubuntu/oneiric-images/nano/mx53loco-nano.i…>, to create the disc and it can work well and I can run my program in this Nano linaro. # What I want: I wanted to build a kernel to replace the kernel installed with linaro Naro 12.02. # My steps: 1) Download the kernel source code: I downloaded the code under the linaro 12.02 download page( http://www.linaro.org/downloads/1202), linux-linaro-lt-freescale<http://launchpad.net/linaro-landing-team-freescale>(supplied by landing team). 2) Build the kernel: I copied the configuration file from micor-SD card, /media/rootfs/config-3.1.0-1002-linaro-It-mx5, and rename it to .config. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules 3) Install kernel to micro-SD card: $ cp arch/arm/boot/uImage /media/boot $ make ARCH=arm INSTALL_MOD_PATH=/media/rootfs modules_install $ sudo umount /media/* 4) Boot with my own kernel: Install the micro-SD card and press power button. # Result: There was no any response after following logs: Starting kernel ... Uncompressing Linux... done, booting the kernel. I have tried several other version kernel code and even update u-boot, but failed to fix it. Could somebody show me suggestion on it? Best Regards, Tim

13 years, 6 months

1
1
0 0

Re: Contents of linaro-kernel digest...

by Wang wenbing

Hi,requrst for linaro-kernel mailing list submissions

13 years, 6 months

1
0
0 0

[ACTIVITY] (John Stultz) May 21-25

by John Stultz

=== Highlights === * I can't take credit for it, but wakelocks landed in 3.5! * Continued reworking the volatile range code to use fallocate * Integrated Hugh Dicken's tmpfs fallocate hole punch changes into my fallocate volatile code. * Got the fallocate volatile patchset functioning and cleaned up, then submitted to lkml for review. * Reviewed and discussed community leapsecond improvement patches * Pushed a few ntp cleanups to tglx * Preped and ran bi-weekly android upstreaming subteam call * Took a first pass at forward porting the AOSP tree to early 3.5-rc * Chased down (with Arnd's help) mmc issue on Panda * Reported hdmi issue on panda * Reported tty_lock lockdep issue to lkml === Plans === * Discuss and integrate any review feedback into volatile range code. * Update the 3.5 Android fwdport tree * Test upstreamed wakelocks w/ Android environment. === Issues === NA

13 years, 6 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-05-21 - 2012-05-25

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Sent pull requests to Torvalds to merge the pinctrl subsystem updates for the v3.5 merge window, he accepted it and merged the stuff. * The ARM SoC portions of Ux500 including basic U9540 support and Ux500 pin control was pulled in by Torvalds. * Investigated a ux500 boot failure on Torvalds kernel, detected last week in the linux-next tree, found that it was caused by two orthogonal approaches to do pin control on the PL011 UART. Coded a fix and sent out, ACK from Shawn Guo, waiting for Greg to pick this into the TTY tree after the merge window closes. * Worked on a pinctrl presentation for Linaro Connect. === Plans === * Vacation: 23 june -> 30 june 9 july -> 3 august (preliminary) * Prepare for travel to Linaro Connect. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... like - Ux500 clocks (looks like a new assignee might look into this) - the HWMON stuff. === Issues === * N/A Thanks, Linus Walleij

13 years, 6 months

1
0
0 0

[PATCH v4 0/16] Merge ram_console into pstore, and more

by Anton Vorontsov

Hi all, A brand new v4: - Per Kees Cook's comments, the patches no longer remove an automatic updates feature, but instead make the it configurable; plus disable it by default (in a separate patch); - Fixed some bugs noticed by Colin Cross; - Documented new continuous ramoops-console log behaviour (also noticed by Colin Cross). In v3: - Rebased on top of current staging-next; - The series are getting bigger. This is partly because we now support different persistent zone sizes for oops records and console log, per Colin Cross' request. And I believe the code is now more manageable for further enhancements (e.g. if we'd want to add other message types, e.g. tracing); - Addressed Kees Cook's comments on the unlinking matters; - Removed automatic updates support. Please see the last patch description for rationale; - A new fixup for pstore/inode, just getting rid of a sparse warning. In v2: - Updated documentation per Colin Cross' comments; - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook); - Fixed large writes handling in pstore_console_write(), i.e. when log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook. And a boilerplate for the series: Currently pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE, plus make pstore/ram.c handle the new messages. The old ram_console driver is removed. This might probably cause some pain for out-of-tree code, as it would need to be adjusted... but "no pain, no gain"? :-) Though, if there's some serious resistance, we can probably postpone the last two patches. Thanks! --- Documentation/ramoops.txt | 14 ++ drivers/staging/android/Kconfig | 5 - drivers/staging/android/Makefile | 1 - drivers/staging/android/ram_console.c | 179 -------------------------- fs/pstore/Kconfig | 7 + fs/pstore/inode.c | 5 +- fs/pstore/platform.c | 49 ++++++- fs/pstore/ram.c | 228 ++++++++++++++++++++++++++------- fs/pstore/ram_core.c | 108 +++------------- include/linux/pstore.h | 1 + include/linux/pstore_ram.h | 22 +--- 11 files changed, 272 insertions(+), 347 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

6
35
0 0

[ACTIVITY] (Anton Vorontsov) 2012-05-07 - 2012-05-18

by Anton Vorontsov

== Highlights == * Found and fixed a few bugs in persistent_ram and pstore, the fixes are already merged; * Consolidated persistent_ram and ramoops, added ECC suppport for ramoops. This is now called 'a generic pstore RAM backend'. So persistent_ram is moved out of staging/android/ directory, and is considered useful for the rest of (i.e. non-Android) world. The backend will handle dmesg, console and tracing messages. The consolidation patches are already in linux-next, and I guess they're heading v3.5. * Sent out a bunch of patches that add console support for pstore (this is ram_console replacement). This is probably v3.6 material. * Started looking into adding tracing support to pstore. * Got a somewhat intense comments on the vmevents subsystem. The bad news is that, according to the comments, vmevent is in not a good shape: it is not generic enough to make -mm folks happy. But the good news is that -mm folks finally looked at the code itself, and we know (to some degree) what is exactly wrong with it. So, hurrah! * Not much progress on AOSP and ulmkd integration. Just built Android images to work with on my current laptop, but so far didn't look into build system itself. == Plans == * Continue work on tracing support for pstore. * Resume work on vmevents, have some patches ready by the end of this week. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

2
2
0 0

[ACTIVITY] (Shawn Guo) Week of May 14

by Shawn Guo

=== Highlights === * Sent a couple of patches to add gpio-range support for pinctrl-mxs driver. Dong commented a bit on that and came up with a proposal to support it at pinctrl core level. * Sent a patch to fix gpio-generic driver on shadow variable initialization. Grant picked it up for v3.5. * Added initial support for imx6dl support. As it's a derivative of imx6q and highly compatible with imx6q, the effort is only about dts tweaking for the initial support. * Reviewed the platform part of the imx-usb series from Richard and and tested it on imx28 with brand new DT support. With a few lines of clk lookup and dts changes, the driver tested on imx6q beforehand starts working nicely for imx28. * Collected a number of fixes on imx platform pinctrl. -- Regards, Shawn

13 years, 6 months

1
0
0 0

[PATCH v3 0/14] Merge ram_console into pstore, and more

by Anton Vorontsov

Hi all, Here comes v3: - Rebased on top of current staging-next; - The series are getting bigger. This is partly because we now support different persistent zone sizes for oops records and console log, per Colin Cross' request. And I believe the code is now more manageable for further enhancements (e.g. if we'd want to add other message types, e.g. tracing); - Addressed Kees Cook's comments on the unlinking matters; - Removed automatic updates support. Please see the last patch description for rationale; - A new fixup for pstore/inode, just getting rid of a sparse warning. In v2: - Updated documentation per Colin Cross' comments; - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook); - Fixed large writes handling in pstore_console_write(), i.e. when log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook. And a boilerplate for the series: Currently pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE, plus make pstore/ram.c handle the new messages. The old ram_console driver is removed. This might probably cause some pain for out-of-tree code, as it would need to be adjusted... but "no pain, no gain"? :-) Though, if there's some serious resistance, we can probably postpone the last two patches. Thanks! --- Documentation/ramoops.txt | 14 ++ drivers/staging/android/Kconfig | 5 - drivers/staging/android/Makefile | 1 - drivers/staging/android/ram_console.c | 179 -------------------------- fs/pstore/Kconfig | 7 + fs/pstore/inode.c | 5 +- fs/pstore/platform.c | 70 +++++----- fs/pstore/ram.c | 228 ++++++++++++++++++++++++++------- fs/pstore/ram_core.c | 109 ++++------------ include/linux/pstore.h | 1 + include/linux/pstore_ram.h | 22 +--- 11 files changed, 269 insertions(+), 372 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 6 months

4
20
0 0

[ACTIVITY] (John Stultz) May 7-8 & 17-18

by John Stultz

=== Highlights === * Pushed a handful of cleanup patches from the linaro-android tree to AOSP and got them merged into the Android tree * Went on vacation from 5/9 -> 5/16 * Got back from vacation, managed to churn through most of my email. * Updated the linaro-android-3.4 tree w/ the latest bits from the AOSP tree * Started discussions about integrating android-3.4-compat tree w/ linaro-android-3.4 * Met with Deepak and started generating details for Android upstreaming session at connect * Synced with Rafael about wakelock patch status for 3.5 * Synced with Anton about his recent ramconsole work === Plans === * Get back to falloc volatile range rework * Address Hugh Dickins' ashmem patch * Prep some time related patches for 3.5 merge window * Further prep for remote Linaro Connect attendence === Issues === NA

13 years, 6 months

2
4
0 0

[ACTIVITY] (Dong Aisheng) May-14-May-18

by Dong Aisheng

=== Highlights === * reviewed mxs pinctrl gpio support patch * sent pinctrl mx5(mx51/mx53) v2 patch, merged by Linus. * pinctrl gpio standard common binding support Sent out v1/v2 patch. Already got some agreement on the standard binding way after some discussion with Stephen Warren. * sent out a few pinctrl core fix and clean up patches * Reviewed some imx pinctrl converting patches. === Plan === * complete standard pinctrl gpio dt binding. * pinctrl per bin based config in the same group investigate and implement

13 years, 6 months

1
0
0 0

[ACTIVITY] (Rajanikanth HV) 2012-05-14 to 2012-05-18

by Rajanikanth HV

==== highlights ==== 1. UBUNTU Distro setup on Laptup, This took approximately 1.5 days including necessary setup - Extended support for Raj on UBUNTU Setup 2. New staff tasks: Found following issues while using: 2.1 Linaro Calender: Could not get the link for "Kernel Working Group" 2.2 Thunderbird Mail setup: https://wiki.linaro.org/Internal/Process/ThunderbirdSetup Setup instruction conveyed in the URL above does not help 3. Device Tree: - Obtained review comments from Lee Jones regarding platform structure support for ab8500 device entries Implementing the same. - Found issues in exporting platform data structure from board file to driver, debugging / root-causing the issue. 4.Support - Looked into the issue highlighted by Mathieu on Uboot with DT, Could not repro kernel panic issue as mathieu is observing. - Assisted appala (Newly joined member) for on boarding tasks ===== Plan ==== 1. Continue to support mathieu 2. Continue debugging platform structure support and complete ==== Issues ====

13 years, 7 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-05-12 - 2012-05-20

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Ux500 pinctrl has landed in the ARM SoC tree. * Merged: - i.MX51 pinctrl driver (Dong Aisheng) - i.MX53 pinctrl driver (Dong Aisheng) - Various pinctrl fixes (Dong, Shawn, Stephen & friends) * Closed the pinctrl tree for the imminent merge window. * Reviewed some incoming GPIO patches in an attempt to offload Grant. * Investigated a ux500 boot failure on -next, not sure of what is causing this. (Reported by Lee Jones.) * Worked on a pinctrl presentation for Linaro Connect. === Plans === * Prepare for travel to Linaro Connect. * Review incoming pinctrl patches. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... like - Ux500 clocks (looks like a new assignee might look into this) - the HWMON stuff. === Issues === * This was a short week in Sweden, out of office thursday+friday. Thanks, Linus Walleij

13 years, 7 months

1
0
0 0

[PATCH v2 0/6] Merge ram_console into pstore

by Anton Vorontsov

Hi all, In v2: - Updated documentation per Colin Cross' comments; - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook); - Fixed large writes handling in pstore_console_write(), i.e. when log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook. These patches depend on the the following series: http://thread.gmane.org/gmane.linux.kernel/1298642 "[PATCH v3 0/3] Merge ramoops and persistent_ram, generic pstore RAM backend" And a rationale for the series: Currently pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE, plus make pstore/ram.c handle the new messages. The old ram_console driver is removed. This might probably cause some pain for out-of-tree code, as it would need to be adjusted... but "no pain, no gain"? :-) Though, if there's some serious resistance, we can probably postpone the last two patches. Thanks! -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 7 months

4
14
0 0

[PATCH v3 0/3] Merge ramoops and persistent_ram, generic pstore RAM backend

by Anton Vorontsov

Hi all, Here comes v3: - Rebased on current staging-next tree, so only 3 patches left; - Fixed ram_console dependency in Kconfig (issue noticed by Greg KH). And the boilerplate, background for the series: There are currently two competing debug facilities to store kernel messages in a persistent storage: a generic pstore and Google's persistent_ram. Not so long ago (https://lkml.org/lkml/2012/3/8/252), it was decided that we should fix this situation. Recently ramoops has switched to pstore, which basically means that it became a RAM backend for the pstore framework. persistent_ram+ram_console and ramoops+pstore have almost the same features, except: 1. Ramoops doesn't support ECC. Having ECC is useful when a hardware reset was used to bring the machine back to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat corrupt, but usually it is restorable. 2. Pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write a reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. These patches solve the first issue, plus move things to their proper places. --- Documentation/ramoops.txt | 6 + drivers/staging/android/Kconfig | 10 +- drivers/staging/android/Makefile | 1 - drivers/staging/android/persistent_ram.c | 532 ------------------------------ drivers/staging/android/persistent_ram.h | 82 ----- drivers/staging/android/ram_console.c | 2 +- fs/pstore/Kconfig | 7 +- fs/pstore/Makefile | 2 +- fs/pstore/ram.c | 119 ++++--- fs/pstore/ram_core.c | 532 ++++++++++++++++++++++++++++++ include/linux/pstore_ram.h | 81 +++++ 11 files changed, 697 insertions(+), 677 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 7 months

3
6
0 0

[ACTIVITY] (Saugata Das) May 14th - May 18th

by Saugata Das

== Saugata Das sdas == === Activity Summary === * Pushed 4KB native sector patch in mmc-next (https://blueprints.launchpad.net/linux-linaro/+spec/emmc4.5-native-sector) * Resubmitted "req meta" patch in ext4 and fsdevel mailing list (https://blueprints.launchpad.net/linux-linaro/+spec/emmc4.5-data-tag) * Submitted RFC patch on context ID in ext4, fsdevel, mmc mailing list (https://blueprints.launchpad.net/linux-linaro/+spec/emmc4.5-context-id) * Resubmitted power OFF notify patch in mmc mailing list * Work ongoing on studying Tixy's traces * Work ongoing on ext4 mkfs study https://blueprints.launchpad.net/linux-linaro/+spec/journal-enhanced-emmc) === Plans === * Continue working on Tixy's traces and mkfs === Issues === * None

13 years, 7 months

1
0
0 0

[PATCH v2 0/6] Merge ramoops and persistent_ram, generic pstore RAM backend

by Anton Vorontsov

Hi all, Here is v2 of the previous patch set. The series do not include patches that were already merged. I believe I addressed all the previous comments, plus now the series include another small cleanup patch. Here's some background for the series: There are currently two competing debug facilities to store kernel messages in a persistent storage: a generic pstore and Google's persistent_ram. Not so long ago (https://lkml.org/lkml/2012/3/8/252), it was decided that we should fix this situation. Recently ramoops has switched to pstore, which basically means that it became a RAM backend for the pstore framework. persistent_ram+ram_console and ramoops+pstore have almost the same features, except: 1. Ramoops doesn't support ECC. Having ECC is useful when a hardware reset was used to bring the machine back to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat corrupt, but usually it is restorable. 2. Pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write a reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. These patches solve the first issue, plus move things to their proper places. Patches that will fix the second issue will be sent shortly. --- Documentation/ramoops.txt | 8 +- drivers/char/Kconfig | 9 - drivers/char/Makefile | 1 - drivers/char/ramoops.c | 362 -------------------- drivers/staging/android/Kconfig | 10 +- drivers/staging/android/Makefile | 1 - drivers/staging/android/persistent_ram.c | 530 ----------------------------- drivers/staging/android/persistent_ram.h | 84 ----- drivers/staging/android/ram_console.c | 2 +- fs/pstore/Kconfig | 17 + fs/pstore/Makefile | 3 + fs/pstore/ram.c | 383 +++++++++++++++++++++ fs/pstore/ram_core.c | 532 ++++++++++++++++++++++++++++++ include/linux/pstore_ram.h | 98 ++++++ include/linux/ramoops.h | 17 - 15 files changed, 1042 insertions(+), 1015 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 7 months

5
16
0 0

[PATCH 0/6] Merge ram_console into pstore

by Anton Vorontsov

Hi all, Currently pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE, plus make pstore/ram.c handle the new messages. The old ram_console driver is removed. This might probably cause some pain for out-of-tree code, as it would need to be adjusted... but "no pain, no gain"? :-) Though, if there's some serious resistance, we can probably postpone the last two patches. These patches depend on the following series: http://thread.gmane.org/gmane.linux.kernel/1298179 "[PATCH v2 0/6] Merge ramoops and persistent_ram, generic pstore RAM backend" Thanks! --- Documentation/ramoops.txt | 15 +++ drivers/staging/android/Kconfig | 5 - drivers/staging/android/Makefile | 1 - drivers/staging/android/ram_console.c | 179 --------------------------------- fs/pstore/Kconfig | 7 ++ fs/pstore/inode.c | 3 + fs/pstore/platform.c | 25 +++++ fs/pstore/ram.c | 39 +++++-- fs/pstore/ram_core.c | 81 +-------------- include/linux/pstore.h | 1 + include/linux/pstore_ram.h | 19 ---- 11 files changed, 83 insertions(+), 292 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years, 7 months

5
17
0 0

Common struct clk for Versatile Express

by Jon Medhurst (Tixy)

Hi All Does anyone know of any efforts or plans to port Versatile Express to the common struct clk? -- Tixy

13 years, 7 months

4
5
0 0

[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, 7 months

5
11
0 0

PATCH: add small infrastructure and definitions to export debugfs files for OMAP powerdomain attributes

by eric van tassell

- These changes make OMAP power state register fields available as attributes per field in debugfs decoded as text with the hex value - pwrdm_read_reg_field() might replace a lot of the explicit functions for reading register fields and clean up the existing OMAP code a bit. - the changes are usable via debugfs standalone or with the patch coming for powerdebug - I've only implemented the support for the MPU PD - to support additional the other powerdomains all that's needed is to add the register_def_t's and field_def_t's here's a screenshot: ./powerdebug -P -d failed to initialize sensors Power Domain Information: ******************* mpu_pwrdm context lostcontext_dff 0:false lostmem_l1 0:false lostmem_l2 0:false lostmem_ram 0:false rstst emulation_rst 0:false pwrstctl powerstate 3:on-active logicretstate 1:whole lowpowerstatechange 0:false l1_retstate 1:retention l2_retstate 1:retention ram_retstate 1:retention l1_onstate 3:on-active l2_onstate 3:on-active ram_onstate 3:on-active pwrst powerstatest 3:on-active logicstatest 1:on l1_statest 3:on-active l2_statest 3:on-active ram_statest 3:on-active intransition 0:false lastpowerstateentered 3:on-active and the patch against Linaro 12.04 kernel is: >From 4b762379805848eebd3454d6bb344a50012069d4 Mon Sep 17 00:00:00 2001 From: Eric van Tassell <evt(a)evtM17x.(none)> Date: Sat, 5 May 2012 15:05:48 -0500 Subject: [PATCH] + basic infrastructure for creating powerdomain attribute files in debugfs + definitions to create the attributes for mpu power domain --- arch/arm/mach-omap2/pm-debug.c | 4 ++ arch/arm/mach-omap2/pm44xx.c | 3 +- arch/arm/mach-omap2/powerdomain.c | 89 +++++++++++++++++++++++++++ arch/arm/mach-omap2/powerdomain.h | 46 +++++++++++++- arch/arm/mach-omap2/powerdomain44xx.c | 23 +++++++ arch/arm/mach-omap2/powerdomains44xx_data.c | 85 +++++++++++++++++++++++++ arch/arm/mach-omap2/prm44xx.h | 1 + 8 files changed, 254 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 4411163..2e365e3 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -224,6 +224,10 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir) (void) debugfs_create_file("suspend", S_IRUGO|S_IWUSR, d, (void *)pwrdm, &pwrdm_suspend_fops); +#ifdef CONFIG_PM_DEBUG + if (d) + pwrdm_create_register_dirs(pwrdm, d); +#endif // CONFIG_PM_DEBUG return 0; } diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 4ab9b9d..f5c189e 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -155,7 +155,7 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused) } -static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) +static int __init pwrdms_setup(struct powerdomain *pwrdm, void *arg) { struct power_state *pwrst; @@ -365,6 +365,7 @@ static int __init omap4_pm_init(void) OMAP44XX_IRQ_PRCM); goto err2; } + ret = pwrdm_for_each(pwrdms_setup, NULL); if (ret) { pr_err("Failed to setup powerdomains\n"); diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 8a18d1b..b392760 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -37,6 +37,11 @@ #define PWRDM_TRACE_STATES_FLAG (1<<31) +#ifdef CONFIG_PM_DEBUG +#include "prm-regbits-44xx.h" +#include <linux/debugfs.h> +#endif // CONFIG_PM_DEBUG + enum { PWRDM_STATE_NOW = 0, PWRDM_STATE_PREV, @@ -201,6 +206,90 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) /* Public functions */ +#ifdef CONFIG_PM_DEBUG +///////////////////////////////////////////////////////////////////////////// +int pwrdm_read_reg_field(field_def_t *f) +{ + int ret = -EINVAL; + + + if (!f ) + return -EINVAL; + + if (!(f->reg)) + return -EINVAL; + + if (!f->reg->pwrdm) + return -EINVAL; + + if (arch_pwrdm && arch_pwrdm->pwrdm_read_reg_field) + ret = arch_pwrdm->pwrdm_read_reg_field(f); + return ret; +} + +#define BUFMAX 4096 +static char scratch[BUFMAX]; + + +static ssize_t pwrdm_dbg_read(struct file *file, char __user *buf, + size_t count, loff_t *ppos) +{ + field_def_t *f = (field_def_t *)file->private_data; + int n; + int val; + + val = pwrdm_read_reg_field(f); + memset(scratch, 0, BUFMAX); + n = sprintf(scratch, "%d:%s", val, f->decoder(val)); + return simple_read_from_buffer(buf, count, ppos, scratch, n + 1); +} + +static int pwrdm_dbg_open(struct inode *inode, struct file *file) +{ + file->private_data = inode->i_private; + return 0; +} + +static const struct file_operations pwrdm_dbg_ops = { + .read = pwrdm_dbg_read, + .open = pwrdm_dbg_open, +}; +/////////////////////////////////////////////////////////////////////////////debug + +static void pwrdm_create_1register_dir(register_def_t *r, struct dentry *pd_dentry) +{ + struct dentry *reg_dentry; + int i; + + reg_dentry = debugfs_create_dir(r->name, pd_dentry); + for (i = 0; i < r->num_fields; i++) { + field_def_t *f = &(r->fields[i]); + + f->reg = r; // link field to register + + debugfs_create_file(f->name, + S_IRUGO, + reg_dentry, + (void *)&(r->fields[i]), + &pwrdm_dbg_ops); + } +} + +void pwrdm_create_register_dirs(struct powerdomain *p, struct dentry *pd_dentry) +{ + int i; + + if ((p == (struct powerdomain *)NULL) || (pd_dentry == (struct dentry *)NULL)) + return; + + for (i = 0; i < p->num_reg_defs; i++) { + p->register_defs[i]->pwrdm = p; + pwrdm_create_1register_dir(p->register_defs[i], pd_dentry); + } +} + +#endif // CONFIG_PM_DEBUG + /** * pwrdm_register_platform_funcs - register powerdomain implementation fns * @po: func pointers for arch specific implementations diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 0d72a8a..5eaf08c 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -76,6 +76,47 @@ struct clockdomain; struct powerdomain; +#ifdef CONFIG_PM_DEBUG +/* general PD decoder definitions */ + +/* field definitions for PD_MPU */ + +typedef struct { + char *name; + u32 shift; + u32 mask; + char * (*decoder)(u8); // note: decoder may be NULL + struct _register_def_t_ *reg; +} field_def_t; + +typedef struct _register_def_t_ { + u32 ix; + char *name; + field_def_t *fields; + u8 num_fields; + struct powerdomain *pwrdm; +} register_def_t; + +#define NUM_ELTS(whole, part) (sizeof(whole)/sizeof(part)) +#define NUM_FIELDS(whole) (sizeof(whole)/sizeof(field_def_t)) + +#define DECODER(name) \ + char *decode_##name(u8 ix) { \ + if (ix > sizeof(name)/sizeof(char *)) \ + return "*invalid*"; \ + else \ + return name[ix]; \ +} + +#define FIELD_ATTR(name_str, base_name, funcp) \ + { \ + .name = name_str, \ + .shift = base_name ## _SHIFT , \ + .mask = base_name ## _MASK , \ + .decoder = funcp \ + } + +#endif //CONFIG_PM_DEBUG /** * struct powerdomain - OMAP powerdomain @@ -124,6 +165,8 @@ struct powerdomain { #ifdef CONFIG_PM_DEBUG s64 timer; s64 state_timer[PWRDM_MAX_PWRSTS]; + register_def_t **register_defs; + int num_reg_defs; #endif }; @@ -149,6 +192,7 @@ struct powerdomain { * @pwrdm_wait_transition: Wait for a pd state transition to complete */ struct pwrdm_ops { + int (*pwrdm_read_reg_field)(field_def_t *f); int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst); int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm); int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm); @@ -173,6 +217,7 @@ int pwrdm_register_platform_funcs(struct pwrdm_ops *custom_funcs); int pwrdm_register_pwrdms(struct powerdomain **pwrdm_list); int pwrdm_complete_init(void); +void pwrdm_create_register_dirs(struct powerdomain *p, struct dentry *pd_dentry); struct powerdomain *pwrdm_lookup(const char *name); int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user), @@ -237,5 +282,4 @@ extern u32 omap2_pwrdm_get_mem_bank_stst_mask(u8 bank); extern struct powerdomain wkup_omap2_pwrdm; extern struct powerdomain gfx_omap2_pwrdm; - #endif diff --git a/arch/arm/mach-omap2/powerdomain44xx.c b/arch/arm/mach-omap2/powerdomain44xx.c index a7880af..3d6d026 100644 --- a/arch/arm/mach-omap2/powerdomain44xx.c +++ b/arch/arm/mach-omap2/powerdomain44xx.c @@ -44,6 +44,28 @@ static int omap4_pwrdm_read_next_pwrst(struct powerdomain *pwrdm) return v; } +static int omap4_pwrdm_read_reg_field(field_def_t *f) +{ + u32 v; + struct powerdomain *pwrdm; + register_def_t *reg; + + if ((reg = f->reg) == (register_def_t *)NULL) + return(0xdeadbeee); + + if ((pwrdm = reg->pwrdm) == (struct powerdomain *)NULL) + return(0xdeadbeef); + + v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, + pwrdm->prcm_offs, + reg->ix); + v &= f->mask; + v >>= f->shift; + return v; + + +} + static int omap4_pwrdm_read_pwrst(struct powerdomain *pwrdm) { u32 v; @@ -210,6 +232,7 @@ static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm) struct pwrdm_ops omap4_pwrdm_operations = { .pwrdm_set_next_pwrst = omap4_pwrdm_set_next_pwrst, .pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst, + .pwrdm_read_reg_field = omap4_pwrdm_read_reg_field, .pwrdm_read_pwrst = omap4_pwrdm_read_pwrst, .pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst, .pwrdm_set_lowpwrstchange = omap4_pwrdm_set_lowpwrstchange, diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c index fbd4c5f..45d4a03 100644 --- a/arch/arm/mach-omap2/powerdomains44xx_data.c +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c @@ -30,6 +30,83 @@ #include "prm44xx.h" #include "prcm_mpu44xx.h" +#if CONFIG_PM_DEBUG + +char *pwrst_vals[] = {"off", "retention", "on-inactive", "on-active"}; +char *boolean_vals[] = {"false", "true"}; +char *statest_vals[] = {"off", "retention", "on-inactive", "on-active"}; +char *logicst_vals[] = {"off", "on"}; +char *logic_retst_vals[] = {"retention regigsters", "whole logic"}; + +DECODER(pwrst_vals); +DECODER(boolean_vals); +DECODER(statest_vals); +DECODER(logicst_vals); +DECODER(logic_retst_vals); + +field_def_t pwrst_fields[] = { + FIELD_ATTR("lastpowerstateentered", OMAP4430_LASTPOWERSTATEENTERED, decode_pwrst_vals), + FIELD_ATTR("intransition", OMAP4430_INTRANSITION, decode_boolean_vals), + FIELD_ATTR("ram_statest", OMAP4430_MPU_RAM_STATEST, decode_statest_vals), + FIELD_ATTR("l2_statest", OMAP4430_MPU_L2_STATEST, decode_statest_vals), + FIELD_ATTR("l1_statest", OMAP4430_MPU_L1_STATEST, decode_statest_vals), + FIELD_ATTR("logicstatest", OMAP4430_LOGICSTATEST, decode_logicst_vals), + FIELD_ATTR("powerstatest", OMAP_POWERSTATEST, decode_pwrst_vals), +}; + +field_def_t pwrstctl_fields[] = { + FIELD_ATTR("ram_onstate", OMAP4430_MPU_RAM_ONSTATE, decode_statest_vals), + FIELD_ATTR("l2_onstate", OMAP4430_MPU_L2_ONSTATE, decode_statest_vals), + FIELD_ATTR("l1_onstate", OMAP4430_MPU_L1_ONSTATE, decode_statest_vals), + FIELD_ATTR("ram_retstate", OMAP4430_MPU_RAM_RETSTATE, decode_statest_vals), + FIELD_ATTR("l2_retstate", OMAP4430_MPU_L2_RETSTATE, decode_statest_vals), + FIELD_ATTR("l1_retstate", OMAP4430_MPU_L1_RETSTATE, decode_statest_vals), + FIELD_ATTR("lowpowerstatechange", OMAP4430_LOWPOWERSTATECHANGE, decode_boolean_vals), + FIELD_ATTR("logicretstate", OMAP4430_LOGICRETSTATE, decode_logic_retst_vals), + FIELD_ATTR("powerstate", OMAP_POWERSTATE, decode_pwrst_vals), +}; + +field_def_t rstst_fields[] = { + + FIELD_ATTR("emulation_rst", OMAP4430_EMULATION_RST, decode_boolean_vals), +}; + +field_def_t ctx_fields[] = { + FIELD_ATTR("lostmem_ram", OMAP4430_LOSTMEM_MPU_RAM, decode_boolean_vals), + FIELD_ATTR("lostmem_l2", OMAP4430_LOSTMEM_MPU_L2, decode_boolean_vals), + FIELD_ATTR("lostmem_l1", OMAP4430_LOSTMEM_MPU_L1, decode_boolean_vals), + FIELD_ATTR("lostcontext_dff", OMAP4430_LOSTCONTEXT_DFF, decode_boolean_vals), +}; + + +register_def_t omap4_mpu_pwrst = {OMAP4_PM_PWSTST, + "pwrst", + pwrst_fields, + NUM_FIELDS(pwrst_fields)}; +register_def_t omap4_mpu_pwrstctl = {OMAP4_PM_PWSTCTRL, + "pwrstctl", + pwrstctl_fields, + NUM_FIELDS(pwrstctl_fields)}; +register_def_t omap4_mpu_rstst = {OMAP4_RM_RSTST, + "rstst", + rstst_fields, + NUM_FIELDS(rstst_fields)}; +register_def_t omap4_mpu_ctx = {OMAP4_RM_MPU_CONTEXT, + "context", + ctx_fields, + NUM_FIELDS(ctx_fields)}; + +register_def_t *omap4_mpu_regs[] = { + &omap4_mpu_pwrst, + &omap4_mpu_pwrstctl, + &omap4_mpu_rstst, + &omap4_mpu_ctx +}; + + +#endif // CONFIG_PM_DEBUG + + /* core_44xx_pwrdm: CORE power domain */ static struct powerdomain core_44xx_pwrdm = { .name = "core_pwrdm", @@ -218,6 +295,10 @@ static struct powerdomain mpu_443x_pwrdm = { [1] = PWRSTS_ON, /* mpu_l2 */ [2] = PWRSTS_ON, /* mpu_ram */ }, +#ifdef CONFIG_PM_DEBUG + .register_defs = omap4_mpu_regs, + .num_reg_defs = NUM_ELTS(omap4_mpu_regs,register_def_t *), +#endif }; static struct powerdomain mpu_446x_pwrdm = { @@ -236,6 +317,10 @@ static struct powerdomain mpu_446x_pwrdm = { [0] = PWRSTS_ON, /* mpu_l2 */ [1] = PWRSTS_ON, /* mpu_ram */ }, +#ifdef CONFIG_PM_DEBUG + .register_defs = omap4_mpu_regs, + .num_reg_defs = NUM_ELTS(omap4_mpu_regs,register_def_t *), +#endif }; /* ivahd_44xx_pwrdm: IVA-HD power domain */ diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 3d66ccd..926257f 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -66,6 +66,7 @@ #define OMAP4_RM_RSTST 0x0008 #define OMAP4_PM_PWSTCTRL 0x0000 #define OMAP4_PM_PWSTST 0x0004 +#define OMAP4_RM_MPU_CONTEXT 0x0024 /* PRM */ -- 1.7.9.5 -- - evt (Eric van Tassell) twitter: evt_texelsoft linked-in: linkedin.com/in/evttxl

13 years, 7 months

3
2
0 0

[ACTIVITY] (Deepak Saxena) May 6 - 12

by Deepak Saxena

=== Highlights === * Synced up with interested parties David R. and Jon M. on Enterprise kernel sessions * Synced up with Grant on DT status and session at connect * Synced up with Michael Hope on STM * Connect session planning === Plans === * Google Hangout on Air interview for marketing/outreach of Connect training sessions. * Continue Connect session planning: creating detailed outlines, coordinating facilitators, slides, etc... * Usual 1:1's and meetings * Work on slides for Upstreaming 101 and Linux Con JP Single zImage presentation. * Work on some wiki page updates === Issues === * Lots to do before leaving, might use all of Portland's coffee supply. === Travel/Time Off === * May 22nd - June 12th: Austin to sync up with Mounir, Rob Herring, Doug Deao Linaro Connect Few days of vacation in Beijing Linux Con Japan A few days of vacation in Tokyo Back Home! * Travel to visit family 7/27 - 8/1. Will be working from CST time zone instead of PST. * Tentatively out August 22nd- Sept 5th. Will be in the middle of nowhere and have no connectivity.

13 years, 7 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel