linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

Is there a mailing list for ask.linaro.org?

by Viresh Kumar

Hi guys, Sorry if i am on the wrong list :( I found it hard to log on to ask.linaro.org to see if i can answer some queries. Or even to ask some queries. I would love to have a mail + mailing-list interface for it. Please point me to one if available. -- viresh

12 years, 8 months

[PATCH V4 0/2] Upstream ST-Ericsson thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> V3->V4 Changes: 1. In previous patch set V3 "Fix thermal bugs and Upstream ST-Ericsson thermal driver", there were 5 patches in total, since the first 3 for fixing thermal layer bugs have been accepted by the maintainer, I'd like to send out the updated last 2 only this time, for upstreaming ST-Ericsson thermal driver. 2. In patch "Thermal: Add ST-Ericsson DB8500 thermal driver" - typo in commit message: diver -> driver; - add more explanation of device tree properties are optional or required. - in function db8500_thermal_match_cdev: remove cdev_name, use trip_points->cdev_name[i] directly instead; - in function db8500_cdev_bind: move cdev->ops->get_max_state(cdev, &max_state) out of for loop to call it only once; - in function db8500_thermal_parse_dt: update checking strlen(tmp_str) >= THERMAL_NAME_LENGTH - add Reviewed-by: Viresh Kumar <viresh.kumar(a)linaro.org> - add Reviewed-by: Francesco Lavra <francescolavra.fl(a)gmail.com> 3. In patch "Thermal: Add ST-Ericsson DB8500 thermal properties and platform data" - add Reviewed-by: Viresh Kumar <viresh.kumar(a)linaro.org> hongbo.zhang (2): Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 2 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile | 2 + drivers/thermal/db8500_cpufreq_cooling.c | 108 +++++ drivers/thermal/db8500_thermal.c | 530 +++++++++++++++++++++ include/linux/platform_data/db8500_thermal.h | 38 ++ 10 files changed, 853 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3

12 years, 8 months

[ACTIVITY] (Shawn Guo) Week of Oct 29

by Shawn Guo

=== Highlights === * Sent imx multi-platform series to arm-soc for 3.8 merge window. * Sent a series adding cpuidle driver for imx6q using coupled cpuidle, implementation 3 C-states - wfi, clock gating and power gating. * Gave FSL internal development team a training on device tree, and spent time on the kernel 3.5 upgrade preparation. Shawn

12 years, 8 months

Do spinlocks really need DMB?

by Peter Fordham

Hi, I'm working with a dual Cortex-A9 system and I've been trying to understand exactly why spinlock functions need to use DMB. It seems that as long as the merging store buffer is flushed the lock value should end up in the L1 on the unlocking core and the SCU should either invalidate or update the value in the L1 of the other core. This is enough to maintain coherency and safe locking right? And doesn't STREX skip the merging store buffer anyway, meaning we don't even need the flush? DMB appears to be something of a blunt hammer, especially since it defaults to the system domain, which likely means a write all the way to main memory, which can be expensive. Are the DMBs in the locks there as a workaround for drivers that don't use smp_mb properly? I'm currently seeing, based on the performance counters, about 5% of my system cycles disappearing in stalls caused by DMB. -Pete

12 years, 8 months

[ACTIVITY] (Anton Vorontsov) 2012-10-08 - 2012-10-26

by Anton Vorontsov

== Highlights == * Got some positive reviews from Mel Gorman on the first RFC of vmevent pressure attribute. Fixed most of implementation comments; * Prepared and sent the second RFC of the pressure attribute support. The new patch integrates Minchan's and Mel's ideas of using discrete pressure levels. Also, now we use reclaimer's priority to detect pre-OOM conditions. The second RFC got some positive feedback from Minchan and Pekka; * Sent accuracy improvements for the vmevent_fd (this fixes a long standing issue noticed by Kosaki Motohiro); * vmevent_fd cleanups were merged into Pekka Enberg's tree; * All the pstore debugfs reworks landed into v3.7-rc1; * Prepared two set of slides for the upcoming Connect: status updates for my items, plus some generic notes on upstreaming; * Resent ARM KDB FIQ support patches, ARM FIQ cleanups and KDB Kiosk mode patches. Still no feedback; * Got some very nice patches for pstore: MMC backend and a tasklist dumper; briefly reviewed the patches, and hopefully they'll be merged in v3.8.

12 years, 8 months

[RFC v2 0/2] vmevent: A bit reworked pressure attribute + docs + man page

by Anton Vorontsov

Hi all, So this is the second RFC. The main change is that I decided to go with discrete levels of the pressure. When I started writing the man page, I had to describe the 'reclaimer inefficiency index', and while doing this I realized that I'm describing how the kernel is doing the memory management, which we try to avoid in the vmevent. And applications don't really care about these details: reclaimers, its inefficiency indexes, scanning window sizes, priority levels, etc. -- it's all "not interesting", and purely kernel's stuff. So I guess Mel Gorman was right, we need some sort of levels. What applications (well, activity managers) are really interested in is this: 1. Do we we sacrifice resources for new memory allocations (e.g. files cache)? 2. Does the new memory allocations' cost becomes too high, and the system hurts because of this? 3. Are we about to OOM soon? And here are the answers: 1. VMEVENT_PRESSURE_LOW 2. VMEVENT_PRESSURE_MED 3. VMEVENT_PRESSURE_OOM There is no "high" pressure, since I really don't see any definition of it, but it's possible to introduce new levels without breaking ABI. The levels described in more details in the patches, and the stuff is still tunable, but now via sysctls, not the vmevent_fd() call itself (i.e. we don't need to rebuild applications to adjust window size or other mm "details"). What I couldn't fix in this RFC is making vmevent_{scanned,reclaimed} stuff per-CPU (there's a comment describing the problem with this). But I made it lockless and tried to make it very lightweight (plus I moved the vmevent_pressure() call to a more "cold" path). Thanks, Anton.

12 years, 8 months

[ACTIVITY] (Linus Walleij) 2012-09-15 - 2012-09-23

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Drilled into the RCU lockup. With some help from Paul McKenney we got a task dump from CPU0 (the CPU that is locking) but not much more - only the swapper thread is running there and we need to dump its stack. * Puffed and pinged on the SPARSE_IRQ patch, yet no reaction so far. * Mainlining some stuff in the PL011 driver that has been sitting internally for some time. Easy stuff went in first and then we ran into the trickier patches - some odd baudrates are impossible since th TTY layer will "snap" the baudrate to a standard baudrate from a table if it's "close enough". We used to work around this by not calling out to the TTY layer in the PL011 driver for certain baudrates, but this is duct-taping. Still debating the real solution with Alan Cox and Russell King who help out a lot. * Reviewed and merged various GPIO patches. * Reviewed and merged various pinctrl patches. * Reviewed some ux500 patches coming from Lee. * Reviewed Arnd's iomem cleanups. * Sent out Patrice Chotard's pinctrl patch for the PL022 SPI driver, Mark has merged it. === Plans === * Ongoing work on sparse IRQ for Nomadik and 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... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * N/A Thanks, Linus Walleij

12 years, 8 months

Connect session: "Kernel Development with Linaro CI and LAVA"

by Michael Hudson-Doyle

Hi all, We'd like to let you know about a session at Connect: http://summit.linaro.org/lce12/meeting/21231/kernel-development-with-linaro… We want to make your jobs easier -- let us know how! Cheers, mwh

12 years, 8 months

[ACTIVITY] (Linus Walleij) 2012-10-13 - 2012-10-22

by Linus Walleij

== Linus Walleij linusw == I realized that my [ACTIVITY] report appears to trigger everyone else to send theirs so when I missed mine, no reports came in, sorry! Here it goes, a weekend late, but still probably the first one. === Highlights === * SPARSE_IRQ patch set for Ux500 ready and rolling, now ready to look at multiplatform for Ux500. * Reviewed and merged some GPIO patches, wrote some GPIO driver patches trying to clean out some irqdomain business, mainly because I don't fully understand the semantics of that API myself. Now I think I do. * Wrote a few U300 patches cleaning up some pinctrl business (irqdomains, nocheinmal). * Again debated issues around runtime PM / suspend and resume proper in the different drivers. We have planned a runtime PM session @connect with Ulf and Amit. * Some heavy lifting as internal adivisor and reviewer of the pinctrl switch for the company. === Plans === * 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. Try something out, get to know it. === Issues === N/A Thanks, Linus Walleij

12 years, 8 months

linker error when using modulo operator in kernel

by Venkatraman S

After making some patch which adds a x = y % z statement in kernel, I get this linker error when trying to compile for Pandboard (omap2plus) undefined reference to `__aeabi_uldivmod' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 Simple search revealed that it's been reported before in linaro gcc and upstream gcc as well. https://bugs.launchpad.net/gcc-linaro/+bug/771832 -> still not resolved. I'm surprised that kernel doesn't use modulo for unsigned long anywhere else except in my patch. Has anyone else seen this or some weird issue in my (typical desktop) setup ? Any workarounds ? TIA, Venkat.

12 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel