linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

ACTIVITY] (Linus Walleij) 2012-08-19 - 2012-08-26

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Arnd pulled in the U300 cleanups and sparse IRQs. * Did one stab to synchronize i2c driver changes from Alessandro Rubini to the internal 3.4 tree, failed (broke Android userspace) now doing it the right way by fixing userspace *FIRST*. * Ongoing work on sparse IRQ for Nomadik and Ux500 * First review of the 11 patches for mvebu pinctrl. * STARTED to review the 14 patches for the RMI4 bus in the input subsystem, which is planned to be used to driver the touchscreen found on all ux500 reference designs, hence I care a lot. Core patches have been reviewed. * Submitted smallish but important fixes to the IRQ flags of ux500 GIC and pinctrl drivers. * Extensive discussions about the mechanics between the ST-Ericsson internal kernel teams and the landing team. We now share common ground and are hashing out the details, much thanks to the positive attitude of involved parties. * Traveling to San Diego for the ARM mini-summit as of writing. === Plans === * Participate in the ARM mini-summit. Hang out with kernel friends and discuss important stuff. * Finalize internalization of the I2C driver, reviewe Lee's DT patches for it and integrate them too, as I get back. * Internalize the PL022 DT 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... using an internal tracking sheet for this. * Look into regmap. === Issues === * N/A Thanks, Linus Walleij

13 years

[PATCH 0/9] Get rid of FIQ_START/enable/disable_fiq() + some FIQ cleanups

by Anton Vorontsov

Hello Russell, During KDB FIQ patches review you mentioned that I should not introduce another FIQ_START. It seems that in v3.6-rc the FIQ_START issue was somewhat band-aided, i.e. machines don't necessary need to define this stuff any longer, but I also read the background of the issue, and you once said that you don't want the FIQ subsystem to mess with genirq. It is surely makes sense as FIQs are arch-specific, plus FIQs are special in that way that platform makers are free to connects device directly to the FIQ line, avoiding IC routing, and then enable_fiq(<IRQ>) would look awkward, at the best. So, given that, it seems that the only entity that knows for sure how the particular FIQ is routed is whoever claims the FIQ and fills-in the fiq_handler struct. It might make sense to introduce disable/enable callbacks in the fiq_handler struct, and then prototypes for disable/ enable FIQ calls would look like this: enable_fiq(struct fiq_handler *fh); disable_fiq(struct fiq_handler *fh); I.e. completely abstracted from the genirq. Although, to not duplicate IC code, I think it's pretty legitimate to call genirq functions iff the caller knows for sure that FIQ comes from IRQ line and it is is routed through the well-known platform IC. In that case (which is a majority), the typical user would do this: static int irq_line; void foo_enable_fiq(struct fiq_handler *fh) { enable_irq(irq_line); } static struct fiq_handler foo_fiq = { .name = "foo", .enable_fiq = foo_enable_fiq, }; claim_fiq(&foo_fiq); enable_fiq(&foo_fiq); Obviously, it's needless indirection, so I don't do this. If we ever pass 'foo_fiq' to some device, which does not know all the routing details, then it would make sense to introduce it, but not now. So, the patch set is pretty straightforward: - Get rid of FIQ_START. Nobody but platform-specific code (and drivers) should know the details about which interrupt can be routed to FIQ and which cannot; - Remove disable/enable_fiq() calls from the FIQ subsys (the calls can be reintroduced w/ new prototypes when/if needed). Does the approach make sense? Thanks! -- arch/arm/include/asm/fiq.h | 2 -- arch/arm/include/asm/mach/irq.h | 9 +++++++-- arch/arm/kernel/fiq.c | 22 +++------------------- arch/arm/kernel/irq.c | 2 -- arch/arm/mach-rpc/dma.c | 4 ++-- arch/arm/mach-rpc/include/mach/irqs.h | 8 ++++---- arch/arm/mach-rpc/irq.c | 21 +++++---------------- arch/arm/mach-s3c24xx/include/mach/irqs.h | 3 --- arch/arm/plat-mxc/avic.c | 4 +--- arch/arm/plat-mxc/include/mach/irqs.h | 2 -- arch/arm/plat-mxc/tzic.c | 4 +--- arch/arm/plat-omap/include/plat/irqs.h | 4 ---- arch/arm/plat-s3c24xx/irq.c | 6 ++---- drivers/media/video/mx1_camera.c | 6 +++--- sound/soc/fsl/imx-pcm-fiq.c | 4 ++-- 15 files changed, 30 insertions(+), 71 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years

How big.little switcher works when it try to boot all cpus in all clusters and then try to switch?

by Lei Wen

Hi Linaro, I get confused when reading the switcher reference code recently: http://git.linaro.org/git/arm/big.LITTLE/switcher.git What I cannot understand is in bootwrapper, that code would be running on all cpus, and then only cpu_id=0 and with BOOT_CLUSTER would be survive to go to the next stage of booting kernel, while the others would be kept in wfi to wait till FLAGS_SET gotten updated. So my question is how could the bootwrapper hind another cpu in one cluster from the kernel's view? I mean how bootwrapper make another cpu in the same cluster as outbound, so that when switch happen, it could take into inbound? In my understand for kernel's SMP, it would bring up all cores later, so I cannot see where kernel could power down another cluster. Anyone could help me out of this? Thanks, Lei

13 years

[PATCH v4 0/8] Function tracing support for pstore

by Anton Vorontsov

Hi all, In v4: - A few cosmetic changes in func_set_flag(), as suggested by Steven Rostedt. Firstly, in the patch that adds pstore option, I use 'else if' for the new bit (it keeps changes minimal), but then there is a new separate patch (the last in the series) that converts the whole thing into a switch construction. In v3: - Make traces versioned, as suggested by Steven, Tony and Colin. (The version tag is stored in the PRZ signature, see the last patch for the implementation details). - Add Steven's Ack on the first patch. 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 | 13 +++++ fs/pstore/Makefile | 1 + fs/pstore/ftrace.c | 35 +++++++++++++ fs/pstore/inode.c | 111 ++++++++++++++++++++++++++++++++++++++-- fs/pstore/internal.h | 43 ++++++++++++++++ fs/pstore/platform.c | 12 ++++- fs/pstore/ram.c | 65 +++++++++++++++++------ fs/pstore/ram_core.c | 12 +++-- include/linux/pstore.h | 13 +++++ include/linux/pstore_ram.h | 3 +- kernel/trace/trace.c | 7 +-- kernel/trace/trace_functions.c | 36 +++++++++---- 13 files changed, 337 insertions(+), 39 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years

[PATCH v4 0/12] KGDB/KDB FIQ (NMI) debugger

by Anton Vorontsov

Hi all, In v4: - Implemented kgdb_nmi serial driver, it provides 'nmi_console' KDB command. With the driver we can use our debugger port as a normal console, except that we can always get back to the debugger using the magic sequence. Note that I still somewhat reluctant to introduce software-raised interrupts, as they're arch-specific and not always possible. So today the driver uses a tasklet, it should be pretty cheap: we're checking for the input on timer interrupts, but we don't cause needless wakeups. The pro of this is that it works everywhere (but arches still have an option to optimize things, of course); - Two new patches added to propagate init_poll() callbacks from tty to uart drivers. As a side-effect, a long-standing bug fixed in amba-pl1011 driver; - Dropped patch 'Get rid of .LCcralign local label'; - Some more fixes in SVC return path. Now it seems rock-solid; - The patches were rebased on the latest Linus' tree, and as usual can be found in the following repo: git://git.infradead.org/users/cbou/linux-nmi-kdb.git master Boilerplate: These patches introduce KGDB FIQ debugger support. The idea (and some code, of course) comes from Google's FIQ debugger[2]. There are some differences (mostly implementation details, feature-wise they're almost equivalent, or can be made equivalent, if desired). The FIQ debugger is a facility that can be used to debug situations when the kernel stuck in uninterruptable sections, e.g. the kernel infinitely loops or deadlocked in an interrupt or with interrupts disabled. On some development boards there is even a special NMI button, which is very useful for debugging weird kernel hangs. And FIQ is basically an NMI, it has a higher priority than IRQs, and upon IRQ exception FIQs are not disabled. It is still possible to disable FIQs (as well as some "NMIs" on other architectures), but via special means. So, here FIQs and NMIs are synonyms, but in the code I use NMI term for arch-independent code, and FIQs for ARM code. A few years ago KDB wasn't yet ready for production, or even not well-known, so originally Google implemented its own FIQ debugger that included its own shell, ring-buffer, commands, dumping, backtracing logic and whatnot. This is very much like PowerPC's xmon (arch/powerpc/xmon), except that xmon was there for a decade, so it even predates KDB. Anyway, nowadays KGDB/KDB is the cross-platform debugger, and the only feature that was missing is NMI handling. This is now fixed for ARM. There are a few differences comparing to the original (Google's) FIQ debugger: - Doing stuff in FIQ context is dangerous, as there we are not allowed to cause aborts or faults. In the original FIQ debugger there was a "signal" software-induced interrupt, upon exit from FIQ it would fire, and we would continue to execute "dangerous" commands from there. In KGDB/KDB we don't use signal interrupts. We can do easier: set up a breakpoint, continue, and you'll trap into KGDB again in a safe context. It works for most cases, but I can imagine cases when you can't set up a breakpoint. For these cases we'd better introduce a KDB command "exit_nmi", that will rise the SW IRQ, after which we're allowed to do anything. - KGDB/KDB FIQ debugger shell is synchronous. In Google's version you could have a dedicated shell always running in the FIQ context, so when you type something on a serial line, you won't actually cause any debugging actions, FIQ would save the characters in its own buffer and continue execution normally. But when you hit return key after the command, then the command is executed. In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the kernel will stop until you instruct it to continue. This might look as a drastic change, but it is not. There is actually no difference whether you have sync or async shell, or at least I couldn't find any use-case where this would matter at all. Anyways, it is still possible to do async shell in KDB, just don't see any need for this. - Original FIQ debugger used a custom FIQ vector handling code, w/ a lot of logic in it. In this approach I'm using the fact that FIQs are basically IRQs, except that we there are a bit more registers banked, and we can actually trap from the IRQ context. But this all does not prevent us from using a simple jump-table based approach as used in the generic ARM entry code. So, here I just reuse the generic approach. Note that I test the code on a modelled ARM machine (QEMU Versatile), so there might be some issues on a real HW, but it works in QEMU tho. :-) Assuming you have QEMU >= 1.1.0, you can easily play with the code using ARM/versatile defconfig and command like this: qemu-system-arm -nographic -machine versatilepb -kernel linux/arch/arm/boot/zImage -append "console=ttyAMA0 kgdboc=ttyAMA0 kgdb_fiq.enable=1" Thanks, -- arch/arm/Kconfig | 19 ++ arch/arm/common/vic.c | 28 +++ arch/arm/include/asm/hardware/vic.h | 2 + arch/arm/include/asm/kgdb.h | 8 + arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +---------------- arch/arm/kernel/entry-header.S | 170 ++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 99 ++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 ++++ drivers/tty/serial/Kconfig | 19 ++ drivers/tty/serial/Makefile | 1 + drivers/tty/serial/amba-pl011.c | 60 +++++-- drivers/tty/serial/kgdb_nmi.c | 348 ++++++++++++++++++++++++++++++++++++ drivers/tty/serial/kgdboc.c | 16 ++ drivers/tty/serial/serial_core.c | 30 ++++ include/linux/kdb.h | 29 +-- include/linux/kgdb.h | 34 ++++ include/linux/serial_core.h | 2 + include/linux/tty_driver.h | 1 + kernel/debug/debug_core.c | 36 +++- kernel/debug/kdb/kdb_main.c | 29 +++ 23 files changed, 1024 insertions(+), 194 deletions(-) In v3: - Per Colin Cross suggestion, added a way to release a debug console for normal use. This is done via 'disable_nmi' command (in the original FIQ debugger it was 'console' command). For this I added a new callback in the tty ops, and serial drivers have to provide a way to clear its interrupts. The patch 'tty/serial/kgdboc: Add and wire up clear_irqs callback' explains the concept in details. - Made the debug entry prompt more shell-like; - A new knocking mode '-1'. It disables the feature altogether, and thus makes it possible to hook KDB entry to a dedicated button. - The code was rebased on 'v3.5 + kdb kiosk'[1] patches; In v2: - Per Colin Cross' suggestion, we should not enter the debugger on any received byte (this might be a problem when there's a noise on the serial line). So there is now an additional patch that implements "knocking" to the KDB (either via $3#33 command or return key, this is configurable); - Reworked {enable,select}_fiq/is_fiq callbacks, now multi-mach kernels should not be a problem; - For versatile machines there are run-time checks for proper UART port (kernel will scream aloud if out of range port is specified); - Added some __init annotations; - Since not every architecture defines FIQ_START, we can't just blindly select CONFIG_FIQ symbol. So ARCH_MIGHT_HAVE_FIQ introduced; - Add !THUMB2_KERNEL dependency for KGDB_FIQ, we don't support Thumb2 kernels; - New patch that is used to get rid of LCcralign label in alignment_trap macro. [1] https://lkml.org/lkml/2012/7/26/260 [2] Original Google's FIQ debugger, fiq_* files: http://android.git.linaro.org/gitweb?p=kernel/common.git;a=tree;f=arch/arm/… And board support as an example of using it: http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commitdiff;h=461cb80c1…

13 years

[ACTIVITY] (Linus Walleij) 2012-08-10 - 2012-08-18

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Cleaned-up and converted U300 to use sparse IRQs * Submitted a devicetree patch set for the Integrator * Fixed two regressions on ux500 in the -rc:s, Lee did fix them similarly in parallell. * Submitted an ASIC ID patch set for the ux500 and synchronized back to the internal 3.4 kernel tree. * Ongoing work on sparse IRQ for Nomadik and Ux500 * Ongoing work to synchronize i2c driver changes from Alessandro Rubini to the internal 3.4 tree. * Reviewed a patch bomb of 22 patches from Lee Jones pertaining to the AB8500 ALSA codec. * Reviewed timer driver for aarch64 generic time. * First review of14 patches for AT91 pinctrl from Jean-Christophe Plaiginol-Villard. * Discussed pinctrl suspend/resume semantics. === Plans === * Invited to participate in the ARM mini-summit in San Diego, accepted and booked travels. * 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. * Look into regmap. === Misc === * Released libmtp 1.1.4 (as if you care). === Issues === * N/A Thanks, Linus Walleij

13 years

[ANN] Userspace low memory killer daemon

by Anton Vorontsov

Hi all, This quite long email (sorry!) has two purposes: to announce userland lowmemory killer daemon to a broader audience, and to resume discussion on lowmemory notifications. The userland lowmemory killer daemon (ulmkd), behaves the same way as kernel's lowmemorykiller (LMK) driver, except that the policy now lives in the userland, and the daemon expects some 'low memory notification' services from the kernel (currently, the main backend is cgroups). Plus, with userland approach now we can send not only SIGKILL, but also user-specific events, upon which programs would not just quit, but would e.g. release/garbage collect memory or we could even try to preemptively suspend and put selected "currently not important" processes into swap (something, I believe, Windows 8 does nowadays, sorry for the analogy. :-) This also seem to slightly relate to fallocate volatile work: the trend is to make resource management a bit smarter, export userland's knowledge about resources to the kernel, give the kernel some hints. ulmkd is a drop-in replacement for lowmemorykiller driver; one can disable CONFIG_ANDROID_LOW_MEMORY_KILLER in the kernel config, start ulmkd, and everything should behave the same way. Also, I do hope the code would be useful not only for Android, so if anybody wants to extend it, you're more than welcome. The code is tiny, and is available in this git repo: git://git.infradead.org/users/cbou/ulmkd.git (The repo is three months old since the stuff seem to just work, at least with cgroups.) The daemon consists of two parts, - Low memory notifications handling; - Task list management. For notifications, there are two backends: cgroups and vmevent. Vmevent support is quite outdated, but it is still there just to show the idea. I plan to substitute it with deferred timer polling + shrinker notifications (see below). For task list management, two methods implemented: /proc based (the daemon reads PIDs and oom_adj values from the /proc directory), and shared memory based, where it is expected that Android Activity Manager (or Maemo, or Tizen manager, or whatever) would keep the task list in the memory, and share it with the killer daemon. The demo_shm.c file provides a small example, it "proxies" task list from /proc to a shared memory. (The Android Activity Manager already manages its own task list, we just need to teach it to share it with the daemon.) Note that we have to implement LMK as a separate small daemon, the reason behind this is best described in Android example: in JVM we can't guarantee 'no new new memory allocations', we're out of control of what JVM does with memory. Plus, we don't want the killer to be swapped out, and so in ulmkd we call mlockall(), thus locking just the small daemon, not the whole JVM. Some words about latency: the reaction time is not a big issue in "Low Memory Killer" duties, this is because LMK triggers when we have plenty of free memory and time (tens and hundreds of megabytes), and OOMK (in-kernel OOM killer) will help us if we're too slow. So ulmkd by no means is going to "replace" OOMK. Note that no matter if we choose to kill processes from kernel or userspace, current in-kernel LMK driver would still need a lot of rework to get it right. The main problem is vm_stat counters. The vm_stat counters are per-node, per-cpu, and gathering the statistics from all the nodes might be quite expensive: e.g. on SMP to synchronize global counters, we'd need to issue an IPI, which, if we presume that we need a low-latency LMK, would disturb the system quite a lot, and the whole point of "light weight" LMK driver defeats itself. In-kernel LMK started when most users where UP/"embedded", so it was all straightforward. But now SMP is quite common setup even on embedded devices, and so we will need to "adjust" LMK to a new reality, sooner or later. And we'd better do it in the best possible way, right from the start. (Note that adding another LRUs, like "easily reclaimable list", doesn't solve the vm_stat issue. Identifying which pages are easily reclaimable is one thing, but statistics is another.) So, in-kernel LMK shares the same issues with vmevent lowmemory notification approach, because both use vm_stat, which we can't update frequently, and so the statistics are not up to date anyway. In ulmkd I want to try another approach (in addition to cgroups): - Considering that we don't have to be super-low-latency, we can just poll /proc/vmstat from userland very infrequently *and* using deferred timers approach to save power, as we did in vmevents -- we won't wake up the system needlessly. As far as I can see, there is no such thing as deferred timers for userland yet, so this is going to be a key part. - Export shrinker notifications to userland (via vmevents API?). This would zap all the discussions about what to consider "low memory", as shrinker is just a small hint that kernel is short on the memory, and we'll OOM pretty soon (assuming no swap). Does it sound viable? Note that nothing is set in stone here, before going all-in into it, I'd really want to hear opinions and more ideas. Thanks! Anton.

13 years

[ACTIVITY] (Linus Walleij) 2012-06-16 - 2012-08-09

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Sent pull requests to Linus Torvalds for pin control and GPIO (as stand-in for Grand Likely). Both for v3.5 fixes before the v3.6 merge window, and the bulk of patches in the merge window, and fixes following the merge window. * My patches to migrate the Integrator and Nomadik machines over to common clk have been accepted upstream and merged to Torvalds. * Invited to participate in the ARM mini-summit in San Diego, accepted and booked travels. * After returning from my vacation I mainly catched up on things, wrote a lot of mail and synced the ST-Ericsson internal development tree in both directions. === Plans === * Look into sparse IRQs for the platforms I know. * 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. * Review a 22-patch bomb from Lee Jones. === Issues === * N/A Thanks, Linus Walleij

13 years

[ACTIVITY] (Anton Vorontsov) 2012-07-23 - 2012-08-03

by Anton Vorontsov

These two weeks have flown by so quickly, I literally had a feeling that the time has been ticking twice as fast. Maybe that is because I had a bunch of small assorted items to do, i.e. no big accomplishments, just a routine. Not all of the items were completed, though; mainly, I still didn't get to LMK, but hopefully FIQ stuff will calm down (I have 27 KDB/FIQ patches already, heh), and so I'll have some time for lowmemory killer. == Highlights == * Finished and sent out thrid version of KGDB/KDB FIQ patch set: in the latest version I introduced disable_nmi command; * Per Russell King's review comments, reworked return path for KGDB FIQ handler (to properly save SVC's SPSR register we have to jump back and forth through the ARM execution modes); * Prepared a set of patches that reworks and cleanups FIQ usage in ARM land (FIQ_START and disable/enable_fiq() calls). Had to carefully audit drivers and subarches; * Addressed Alan Cox's comments on KDB Kiosk mode support patches, reworked and sent out v2 of the patch that adds appropriate flags to the KDB commands; * Started adding 'console' into KDB FIQ. I tried to avoid it as the whole scheme might look ugly (i.e. console->kgdb->FIQ->console), but Colin showed a case where just detaching FIQ is not enough, and so the dedicated KDB FIQ console is mandatory; * Had to spent a bit of time on battery stuff, this merge window pull request has been unusually complicated as there were conflicts with ACPI/thermal tree. Also there were a bunch of patches for review. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

13 years

[ACTIVITY] (John Stultz) July 30 - Aug 3

by John Stultz

=== Highlights === * Sent out LRU_VOLATILE work to lkml. Minimal feedback so far. * Generated some initial statistics on ashmem usage and frequency * Fought with uboot/devicetree trying to replace a kernel on current ubuntu images * Did some initial investagation on using the ETM/ETB driver w/ pandaboard. Got stuck as the driver isn't seemingly finding the device. Not sure if that's a devicetree issue or what. * Chased down a timekeeping regression tripped by a system with a broken CMOS clock. * Continued work generating better test cases for timekeeping. * Started some planning for Kernel Summit/Plumbers discussions * Ran the android upstreaming subteam meeting === Plans === * Take another shot at ETB/ETM work * Further stress testing of the LRU_VOLATILE work using Android's ashmem and adding memory pressure via kernel boot args * Work on slides & presentation for Plumbers === Issues === * None

13 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel