linaro-kernel August 2012

linaro-kernel@lists.linaro.org

32 participants
19 discussions

[Activity] (Omar Ramirez) Aug 6 - Aug 12 2012

by Omar Ramirez Luna

=== omarrmz === * ARMv8t - Compile aarch64 binutils. DONE - Need to recompile the toolchain using the aarch64 binutils. DONE - Compile the aarch64 kernel with aarch64 toolchain: DONE. - Plain config generated through menuconfig. * Mailbox runtime OFF mode: DONE. - Tested on OMAP3 and OMAP4 - Needs to be submitted to LO. * Consolidate iommu changes into original series: IN PROGRESS. * Get some time to do an omap mailbox cleanup: NO UPDATE. - Low priority. * Review patches from Laurent on tidspbridge: IN PROGRESS. - Reviewed 4 fo 13 patches so far. - Review a separate bug he is reporting. === Plans === * Continue to ping Paul for my reset patches in the mailing list. * Keep on looking at aarch64 patches. Regards, Omar

12 years, 5 months

[PATCH 0/4] [RFC] ARM: multiplatform: rename all mach headers

by Arnd Bergmann

I've created this series some time ago, and updated it now to v3.6-rc1. The idea is to get us a big step closer to the single zImage kernel across multiple ARM platforms by untangling the duplicate header file names. There are two branches available in the arm-soc tree: 1. This series, http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=shortlog;h=refs… This just moves header files around and changes most of the files including them. There are a few remaining drivers and platform files that keep including a generic file name like <mach/uncompress.h>. It remains possible to do that, and I've run extensive tests to ensure I did not break anything with this. However, each of these instances means that there is something that stops working when you get to the real multiplatform kernel and we still need to deal with them one by one. 2. Actually enabling CONFIG_ARCH_MULTIPLATFORM http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=shortlog;h=refs… This builds on top of the first series, but is much more experimental. It shows how a multiplatform kernel can look like, by allowing to build vexpress, ux500, imx and omap2 together in one kernel, but at the same time breaking some of their features. I would like to get the first series merged in v3.7 if we can agree on the general approach. So far, feedback in Linaro internal meetings has been very positive, but Russell had concerns when we first discussed it a few months ago. A patch set this large means a lot of churn, and there are a few ways we could deal with this: a) Put the branch into linux-next now, and have everyone who encounters conflicts pull it into their own branch to resolve the conflicts. This can be a lot of work, and it means we cannot rebase this branch any more. b) Involve Linus Torvalds in the process and get him to take the series at the end of the v3.7 merge window, after rebasing it on top of all the other branches he merged. This means it happens pretty much ad-hoc and there is little testing on the patches that actually get merged. c) Split the series and submit the first two branches at the start of the merge window, and do the changes to all the drivers either at the end of the v3.7 merge window (after rebasing) or merge them through the subsystem maintainer trees in small chunks for v3.8. This can minimize the problems of the other two approaches, but means the process takes longer to get to the same result. Arnd [second attempt to send these patches, the first one was rejected by lists.infradead.org, this one uses a different smtp setup] Arnd Bergmann (4): [RFC] ARM: autogenerate mach-foo/* and plat-foo/* header redirects [RFC] ARM: mass move of mach-*/plat-* header files [RFC] ARM: treewide: scripted conversion to mach-*/*.h [RFC] ARM: treewide: manually change more mach-*/*.h includes 0.0% Documentation/spi/ 0.0% arch/arm/boot/compressed/ 2.0% arch/arm/mach-at91/include/mach-at91/ 2.0% arch/arm/mach-at91/include/mach/ 0.1% arch/arm/mach-at91/ 0.0% arch/arm/mach-bcmring/csp/chipc/ 0.0% arch/arm/mach-bcmring/csp/dmac/ 0.0% arch/arm/mach-bcmring/csp/tmr/ 0.0% arch/arm/mach-bcmring/include/csp/ 3.0% arch/arm/mach-bcmring/include/mach-bcmring/csp/ 0.6% arch/arm/mach-bcmring/include/mach-bcmring/ 3.0% arch/arm/mach-bcmring/include/mach/csp/ 0.6% arch/arm/mach-bcmring/include/mach/ 0.0% arch/arm/mach-bcmring/ 0.3% arch/arm/mach-clps711x/include/mach-clps711x/ 0.3% arch/arm/mach-clps711x/include/mach/ 0.0% arch/arm/mach-clps711x/ 0.3% arch/arm/mach-cns3xxx/include/mach-cns3xxx/ 0.3% arch/arm/mach-cns3xxx/include/mach/ 0.0% arch/arm/mach-cns3xxx/ 1.2% arch/arm/mach-davinci/include/mach-davinci/ 1.2% arch/arm/mach-davinci/include/mach/ 0.1% arch/arm/mach-davinci/ 0.1% arch/arm/mach-dove/include/mach-dove/ 0.1% arch/arm/mach-dove/include/mach/ 0.0% arch/arm/mach-dove/ 0.0% arch/arm/mach-ebsa110/include/mach-ebsa110/ 0.0% arch/arm/mach-ebsa110/include/mach/ 0.0% arch/arm/mach-ebsa110/ 0.2% arch/arm/mach-ep93xx/include/mach-ep93xx/ 0.2% arch/arm/mach-ep93xx/include/mach/ 0.0% arch/arm/mach-ep93xx/ 1.0% arch/arm/mach-exynos/include/mach-exynos/ 1.0% arch/arm/mach-exynos/include/mach/ 0.1% arch/arm/mach-exynos/ 0.1% arch/arm/mach-footbridge/include/mach-footbridge/ 0.1% arch/arm/mach-footbridge/include/mach/ 0.0% arch/arm/mach-footbridge/ 0.1% arch/arm/mach-gemini/include/mach-gemini/ 0.1% arch/arm/mach-gemini/include/mach/ 0.0% arch/arm/mach-gemini/ 0.2% arch/arm/mach-h720x/include/mach-h720x/ 0.2% arch/arm/mach-h720x/include/mach/ 0.0% arch/arm/mach-h720x/ 0.0% arch/arm/mach-highbank/include/mach-highbank/ 0.0% arch/arm/mach-highbank/include/mach/ 7.2% arch/arm/mach-imx/include/mach-imx/ 0.0% arch/arm/mach-imx/include/mach/ 0.1% arch/arm/mach-imx/ 0.3% arch/arm/mach-integrator/include/mach-integrator/ 0.3% arch/arm/mach-integrator/include/mach/ 0.0% arch/arm/mach-integrator/ 0.6% arch/arm/mach-iop13xx/include/mach-iop13xx/ 0.6% arch/arm/mach-iop13xx/include/mach/ 0.0% arch/arm/mach-iop13xx/ 0.0% arch/arm/mach-iop32x/include/mach-iop32x/ 0.0% arch/arm/mach-iop32x/include/mach/ 0.0% arch/arm/mach-iop32x/ 0.0% arch/arm/mach-iop33x/include/mach-iop33x/ 0.0% arch/arm/mach-iop33x/include/mach/ 0.0% arch/arm/mach-iop33x/ 0.7% arch/arm/mach-ixp4xx/include/mach-ixp4xx/ 0.7% arch/arm/mach-ixp4xx/include/mach/ 0.0% arch/arm/mach-ixp4xx/ 0.1% arch/arm/mach-kirkwood/include/mach-kirkwood/ 0.1% arch/arm/mach-kirkwood/include/mach/ 0.0% arch/arm/mach-kirkwood/ 0.4% arch/arm/mach-ks8695/include/mach-ks8695/ 0.4% arch/arm/mach-ks8695/include/mach/ 0.0% arch/arm/mach-ks8695/ 0.0% arch/arm/mach-l7200/include/mach-l7200/ 0.0% arch/arm/mach-l7200/include/mach/ 0.4% arch/arm/mach-lpc32xx/include/mach-lpc32xx/ 0.4% arch/arm/mach-lpc32xx/include/mach/ 0.0% arch/arm/mach-lpc32xx/ 1.0% arch/arm/mach-mmp/include/mach-mmp/ 1.0% arch/arm/mach-mmp/include/mach/ 0.0% arch/arm/mach-mmp/ 1.9% arch/arm/mach-msm/include/mach-msm/ 1.9% arch/arm/mach-msm/include/mach/ 0.0% arch/arm/mach-msm/ 0.1% arch/arm/mach-mv78xx0/include/mach-mv78xx0/ 0.1% arch/arm/mach-mv78xx0/include/mach/ 0.0% arch/arm/mach-mv78xx0/ 0.0% arch/arm/mach-mvebu/include/mach-mvebu/ 0.0% arch/arm/mach-mvebu/include/mach/ 0.0% arch/arm/mach-mvebu/ 0.0% arch/arm/mach-mxs/devices/ 1.1% arch/arm/mach-mxs/include/mach-mxs/ 1.1% arch/arm/mach-mxs/include/mach/ 0.0% arch/arm/mach-mxs/ 0.3% arch/arm/mach-netx/include/mach-netx/ 0.3% arch/arm/mach-netx/include/mach/ 0.0% arch/arm/mach-netx/ 0.1% arch/arm/mach-nomadik/include/mach-nomadik/ 0.1% arch/arm/mach-nomadik/include/mach/ 0.0% arch/arm/mach-nomadik/ 0.2% arch/arm/mach-omap1/include/mach-omap1/ 0.2% arch/arm/mach-omap1/include/mach/ 0.1% arch/arm/mach-omap1/ 1.2% arch/arm/mach-omap2/include/mach-omap2/ 1.2% arch/arm/mach-omap2/include/mach/ 0.3% arch/arm/mach-omap2/ 0.1% arch/arm/mach-orion5x/include/mach-orion5x/ 0.1% arch/arm/mach-orion5x/include/mach/ 0.0% arch/arm/mach-orion5x/ 0.0% arch/arm/mach-picoxcell/include/mach-picoxcell/ 0.0% arch/arm/mach-picoxcell/include/mach/ 0.0% arch/arm/mach-picoxcell/ 0.4% arch/arm/mach-pnx4008/include/mach-pnx4008/ 0.4% arch/arm/mach-pnx4008/include/mach/ 0.0% arch/arm/mach-pnx4008/ 0.0% arch/arm/mach-prima2/include/mach-prima2/ 0.0% arch/arm/mach-prima2/include/mach/ 0.0% arch/arm/mach-prima2/ 4.0% arch/arm/mach-pxa/include/mach-pxa/ 4.0% arch/arm/mach-pxa/include/mach/ 0.3% arch/arm/mach-pxa/ 0.7% arch/arm/mach-realview/include/mach-realview/ 0.7% arch/arm/mach-realview/include/mach/ 0.0% arch/arm/mach-realview/ 0.1% arch/arm/mach-rpc/include/mach-rpc/ 0.1% arch/arm/mach-rpc/include/mach/ 0.0% arch/arm/mach-rpc/ 0.0% arch/arm/mach-s3c2410/ 0.0% arch/arm/mach-s3c2412/ 0.0% arch/arm/mach-s3c2440/ 1.4% arch/arm/mach-s3c24xx/include/mach-s3c24xx/ 1.4% arch/arm/mach-s3c24xx/include/mach/ 0.4% arch/arm/mach-s3c24xx/ 0.5% arch/arm/mach-s3c64xx/include/mach-s3c64xx/ 0.5% arch/arm/mach-s3c64xx/include/mach/ 0.1% arch/arm/mach-s3c64xx/ 0.3% arch/arm/mach-s5p64x0/include/mach-s5p64x0/ 0.3% arch/arm/mach-s5p64x0/include/mach/ 0.0% arch/arm/mach-s5p64x0/ 0.2% arch/arm/mach-s5pc100/include/mach-s5pc100/ 0.2% arch/arm/mach-s5pc100/include/mach/ 0.0% arch/arm/mach-s5pc100/ 0.3% arch/arm/mach-s5pv210/include/mach-s5pv210/ 0.3% arch/arm/mach-s5pv210/include/mach/ 0.0% arch/arm/mach-s5pv210/ 1.9% arch/arm/mach-sa1100/include/mach-sa1100/ 1.9% arch/arm/mach-sa1100/include/mach/ 0.0% arch/arm/mach-sa1100/ 0.0% arch/arm/mach-shark/include/mach-shark/ 0.0% arch/arm/mach-shark/include/mach/ 1.5% arch/arm/mach-shmobile/include/mach-shmobile/ 1.5% arch/arm/mach-shmobile/include/mach/ 0.0% arch/arm/mach-shmobile/ 0.0% arch/arm/mach-socfpga/include/mach-socfpga/ 0.0% arch/arm/mach-socfpga/include/mach/ 0.1% arch/arm/mach-spear13xx/include/mach-spear13xx/ 0.1% arch/arm/mach-spear13xx/include/mach/ 0.0% arch/arm/mach-spear13xx/ 0.0% arch/arm/mach-spear3xx/include/mach-spear3xx/ 0.0% arch/arm/mach-spear3xx/include/mach/ 0.0% arch/arm/mach-spear3xx/ 0.0% arch/arm/mach-spear6xx/include/mach-spear6xx/ 0.0% arch/arm/mach-spear6xx/include/mach/ 0.0% arch/arm/mach-spear6xx/ 0.5% arch/arm/mach-tegra/include/mach-tegra/ 0.5% arch/arm/mach-tegra/include/mach/ 0.0% arch/arm/mach-tegra/ 0.5% arch/arm/mach-u300/include/mach-u300/ 0.5% arch/arm/mach-u300/include/mach/ 0.0% arch/arm/mach-u300/ 0.3% arch/arm/mach-ux500/include/mach-ux500/ 0.3% arch/arm/mach-ux500/include/mach/ 0.0% arch/arm/mach-ux500/ 0.3% arch/arm/mach-versatile/include/mach-versatile/ 0.3% arch/arm/mach-versatile/include/mach/ 0.0% arch/arm/mach-versatile/ 0.1% arch/arm/mach-vexpress/include/mach-vexpress/ 0.1% arch/arm/mach-vexpress/include/mach/ 0.0% arch/arm/mach-vexpress/ 0.2% arch/arm/mach-vt8500/include/mach-vt8500/ 0.2% arch/arm/mach-vt8500/include/mach/ 0.0% arch/arm/mach-vt8500/ 0.3% arch/arm/mach-w90x900/include/mach-w90x900/ 0.3% arch/arm/mach-w90x900/include/mach/ 0.0% arch/arm/mach-w90x900/ 0.0% arch/arm/mach-zynq/include/mach-zynq/ 0.0% arch/arm/mach-zynq/include/mach/ 0.0% arch/arm/mach-zynq/ 0.0% arch/arm/mm/ 0.0% arch/arm/plat-mxc/devices/ 7.2% arch/arm/plat-mxc/include/mach/ 0.0% arch/arm/plat-mxc/ 0.1% arch/arm/plat-nomadik/include/plat-nomadik/ 0.1% arch/arm/plat-nomadik/include/plat/ 3.4% arch/arm/plat-omap/include/plat-omap/ 3.4% arch/arm/plat-omap/include/plat/ 0.0% arch/arm/plat-omap/ 0.1% arch/arm/plat-orion/include/plat-orion/ 0.1% arch/arm/plat-orion/include/plat/ 0.0% arch/arm/plat-orion/ 0.2% arch/arm/plat-pxa/include/plat-pxa/ 0.2% arch/arm/plat-pxa/include/plat/ 0.0% arch/arm/plat-pxa/ 0.0% arch/arm/plat-s3c24xx/ 2.7% arch/arm/plat-samsung/include/plat-samsung/ 2.7% arch/arm/plat-samsung/include/plat/ 0.0% arch/arm/plat-samsung/ 0.1% arch/arm/plat-spear/include/plat-spear/ 0.1% arch/arm/plat-spear/include/plat/ 0.0% arch/arm/plat-spear/ 0.0% arch/arm/plat-versatile/include/plat-versatile/ 0.0% arch/arm/plat-versatile/include/plat/ 0.0% arch/arm/plat-versatile/ 0.0% arch/arm/tools/ 0.0% arch/arm/ 0.0% drivers/ata/ 0.0% drivers/char/hw_random/ 0.0% drivers/char/ 0.0% drivers/clk/mxs/ 0.0% drivers/clk/ 0.0% drivers/clocksource/ 0.0% drivers/cpufreq/ 0.0% drivers/crypto/ux500/cryp/ 0.0% drivers/crypto/ux500/hash/ 0.0% drivers/crypto/ 0.0% drivers/devfreq/ 0.0% drivers/dma/ipu/ 0.0% drivers/dma/ 0.0% drivers/gpio/ 0.0% drivers/gpu/drm/exynos/ 0.0% drivers/hwmon/ 0.0% drivers/i2c/busses/ 0.0% drivers/iio/adc/ 0.0% drivers/input/keyboard/ 0.0% drivers/input/misc/ 0.0% drivers/input/mouse/ 0.0% drivers/input/serio/ 0.0% drivers/input/touchscreen/ 0.0% drivers/iommu/ 0.0% drivers/leds/ 0.0% drivers/media/video/davinci/ 0.0% drivers/media/video/omap/ 0.0% drivers/media/video/omap3isp/ 0.0% drivers/media/video/s5p-fimc/ 0.0% drivers/media/video/s5p-tv/ 0.0% drivers/media/video/ 0.0% drivers/mfd/ 0.0% drivers/misc/ 0.0% drivers/mmc/host/ 0.0% drivers/mtd/maps/ 0.0% drivers/mtd/nand/ 0.0% drivers/mtd/onenand/ 0.0% drivers/net/can/ 0.0% drivers/net/ethernet/amd/ 0.0% drivers/net/ethernet/cadence/ 0.0% drivers/net/ethernet/cirrus/ 0.0% drivers/net/ethernet/micrel/ 0.0% drivers/net/ethernet/nxp/ 0.0% drivers/net/ethernet/smsc/ 0.0% drivers/net/ethernet/xscale/ 0.0% drivers/net/ethernet/ 0.0% drivers/net/irda/ 0.0% drivers/net/wan/ 0.0% drivers/pcmcia/ 0.0% drivers/pinctrl/ 0.0% drivers/power/avs/ 0.0% drivers/power/ 0.0% drivers/ptp/ 0.0% drivers/pwm/ 0.0% drivers/remoteproc/ 0.0% drivers/rtc/ 0.0% drivers/scsi/arm/ 0.0% drivers/spi/ 0.0% drivers/staging/nvec/ 0.0% drivers/staging/omapdrm/ 0.0% drivers/staging/ste_rmi4/ 0.0% drivers/staging/tidspbridge/core/ 0.0% drivers/staging/tidspbridge/include/dspbridge/ 0.0% drivers/staging/tidspbridge/rmgr/ 0.0% drivers/tty/serial/ 0.0% drivers/uio/ 0.0% drivers/usb/gadget/ 0.0% drivers/usb/host/ 0.0% drivers/usb/musb/ 0.0% drivers/usb/otg/ 0.0% drivers/video/backlight/ 0.0% drivers/video/exynos/ 0.0% drivers/video/msm/ 0.0% drivers/video/omap/ 0.0% drivers/video/omap2/dss/ 0.0% drivers/video/omap2/omapfb/ 0.0% drivers/video/omap2/ 0.0% drivers/video/pnx4008/ 0.0% drivers/video/ 0.0% drivers/w1/masters/ 0.0% drivers/watchdog/ 0.0% include/linux/mfd/ 0.0% include/linux/platform_data/ 0.0% include/linux/power/ 0.0% include/linux/spi/ 0.0% include/linux/ 0.0% sound/arm/ 0.0% sound/atmel/ 0.0% sound/oss/ 0.0% sound/soc/atmel/ 0.0% sound/soc/davinci/ 0.0% sound/soc/ep93xx/ 0.0% sound/soc/fsl/ 0.0% sound/soc/kirkwood/ 0.0% sound/soc/mxs/ 0.0% sound/soc/nuc900/ 0.0% sound/soc/omap/ 0.0% sound/soc/pxa/ 0.0% sound/soc/samsung/ 0.0% sound/soc/tegra/ 0.0% sound/soc/ux500/

12 years, 5 months

[PATCH 0/2] ST-Ericsson dbx500 thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> This patch sets contains two patches: [PATCH 1/2] Thermal: Move struct thermal_cooling_device_instance to thermal.h Note: Declaration of struct thermal_cooling_device_instance should be moved to public header file thermal.h, because a thermal zone driver need to operate the cooling devices binded to itself sometimes, for example when the thermal mode is set to "disabled", all the cooling devices should be disabled too. This can be done in thermal_sys.c, but it is better to let the user to do it because different kinds of cooling devices may have different behavors. There is no need to maintain a cooling device list by the thermal driver, because the framework has already done so in the list thermal_zone_device->cooling_devices. Thus the thermal_cooling_device_instance is needed when a thermal driver walks throuth the list thermal_zone_device->cooling_devices. [PATCH 2/2] Thermal: Add ST-Ericsson db8500 thermal dirver. Updated: 1. Device tree is supported. 2. thermal_zone_device_register() updated because of framework update in kernel v3.6-rc1 3. Force cooling deveces to be disabled when thermal mode is disabled. Dependences: 1. Lee Jones PRCMU device tree bindings. 2. Acception of the above thermal framewrok modification. hongbo.zhang (2): Thermal: Move struct thermal_cooling_device_instance to thermal.h Thermal: Add ST-Ericsson db8500 thermal dirver. arch/arm/boot/dts/db8500.dtsi | 11 + arch/arm/configs/u8500_defconfig | 4 + arch/arm/mach-ux500/board-mop500.c | 73 ++++ drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile | 4 +- drivers/thermal/db8500_cpufreq_cooling.c | 175 +++++++++ drivers/thermal/db8500_thermal.c | 511 ++++++++++++++++++++++++++ drivers/thermal/thermal_sys.c | 11 - include/linux/platform_data/db8500_thermal.h | 39 ++ include/linux/thermal.h | 12 + 10 files changed, 848 insertions(+), 12 deletions(-) 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.10

12 years, 5 months

Linaro Linux for Cortex-A15?

by Peter Chang

Dear Kernel developer of Linaro: We've bought FastModel to simulate Cortex-A15. But we cannot find out the Linux for running on Cortex-A15. I've also downloaded the latest Linaro Linux from website. But I still cannot find the default configure for Cortex-A15. Is there anyone working for Linaro Linux for Cortex-A15? And is it released? Thank for answer my question. Best wish, Peter Chang

12 years, 5 months

[ACTIVITY] (Anton Vorontsov) 2012-08-06 - 2012-08-24

by Anton Vorontsov

Sorry for the delayed report, the fact that I didn't report anything for three weeks was a surprise for myself, I thought it was "just" two weeks. == Highlights == * Spent quite a lot of time debugging KDB/FIQ random hangs. The hangs were a challenge to debug, although resulted in three lines of code to change (the notorious SVC exit path). But hopefully it's all over and KDB/FIQ now survives all my most strict testcases, and no single hang observed; * So I sent out v4 of KDB/NMI/FIQ debugger: - The new set includes NMI tty and console driver. KDB 'nmi_console' command is used to make debugger shell usable for normal Linux console, but with ability to enter the magic sequence. KDB command 'disable_nmi' is more powerful, it releases NMI, and thus handles serial port back to normal serial driver; - Fixed amba-pl1011 driver polling initialization (and that also fixed another issue the driver, i.e. division by zero if console= and kgdboc= point to different devices). - Some more work on FIQ code cleanup: a new patch that removes init_FIQ() completely (plus maybe fixes a real bug, but yet not sure, let's see how review goes); - Rebased on top of the latest Linus' tree. * Some pstore related work: - I started receiving pstore/ram related patches, so to track the flow I created linux-pstore.git tree. I wanted to merge the fixes into v3.6-rc2, but it didn't make it. So, this is now postponed till v3.7 (linux-pstore tree is now in linux-next, btw). - Got an 'OK' for pstore/ftrace debugfs rework, yay. The patch will be merged into linux-pstore.git tree soon, just need to finish tests. * Announced userland lowmemory killer daemon. Almost no feedback; * Recently there was a flood of battery/charger-related patches for review, so had dedicate some time to it as well; * I looked into latest cgroups kmem/slab accounting work, and I still don't see any way to account slab for root cgroups (i.e. account drivers' memory). It seems that the fact that the root cgroup does not account true kernel memory is the design decision. Time to move on, I guess. We'll probably need some alternative to cgroups anyway. == Plans == * Actually, I started looking into it months ago, but didn't end up with touching any code: I wanted to add 'deferrable' timer into posix timers or timerfd API (or any timers API that is nowadays considered 'mainstream' and would be suitable for these kind of things). The deferred timer means that we want to be notified about the timeout, but only if the system is running, the timer itself won't cause system to wake up. The "problem" with the timer is that I don't see any use-case for it apart from LMK (i.e. polling /proc/vmstat without wasting battery power). And the fact that I could not see other usecases makes me wonder if there's something wrong with the idea. Although, the idea is pretty close to ITIMER_PROF, except that we want to decrement the timer based on the wall clock, but 'when the system is executing'. John, I believe you know a lot more about timers-related things, so maybe you have any advices/directions, based on my thoughts above? * Apart from LMK work, I don't have anything for real 'development'. My main task for now is to get KDB/FIQ into 3.7, but hopefully I can do it in "maintenance mode", thus I guess it is time to start looking at picking other tasks. Is there anything on the priority list?

12 years, 6 months

Cross compiling kernel on ubuntu 12.04(for pandaboard) fails

by Ракитянский Станислав

Hello! I have tried cross compiling linaro kernel for pandaboard using instructions from wiki(using latest kernel source and crossbuild tools), but i'm always getting same error: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KBUILD_DEBARCH=armhf deb-pkg ... ....... 1 hour later: dpkg-deb: building package `linux-firmware-image:armel' in `../linux-firmware-image_3.4.0-2_armel.deb'. dpkg-gencontrol: error: current host architecture 'armhf' does not appear in package's architecture list (armel) make[1]: *** [deb-pkg] Error 255 So i guess thats because all instructions on wiki are very old and can not be used. I have tried to find instuctions on the internet without any success....all the instuction is very old, its even impossible to find where to get lastest linaro kernel source for pandaboard using git! (only way to get it is to download package from dl section on linaro website) Can someone help me please ? What i need: build deb package of last version of linaro kernel for pandaboad es What for ? : adding support of LCD module + webcam. System i'm using: Ubuntu 12.04 64bit. Devboard: PandaBoard ES

12 years, 6 months

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

12 years, 6 months

[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

12 years, 6 months

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

12 years, 6 months

[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

12 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel August 2012