- linaro-kernel - lists.linaro.org

by John Stultz

=== Highlights === * LWN covered my Android Upstreaming Summary here: https://lwn.net/Articles/514901/ * Implemented byte-range management for volatile ranges. * After talking with Thomas last week, I took a first pass at implementing refined-jiffies, which should allow CLOCK_TICK_RATE to be managed dynamically rather then statically. This helps the unified zImage work. * Generated a patch implementing Tixy's suggested fix for the evdev issue he was seeing. Sent it to Rafael for review and then submitted it to lkml. Its queued for 3.7 * Got feedback from Mozilla developers, clarifying what their needs are with respect to the volatile ranges patch * Got weekly Android upstreaming email going again * Replied to questions related to my Android Upstreaming Summary * Followed up on time patches that should be backported to -stable. Generated patch queues for each of the -stable trees. * Did some further work prepping time changes for 3.7 * Investigated time regression in 3.6 * Replied to clock TAI question on the ptp list. === Plans === * Make first pass at sending SIGBUS on accessing purged volatile pages * Finish testing of refined jiffies and send patches out * Finish testing -stable backports, and send patches out === Issues === * NA

12 years, 9 months

2
1
0 0

[ACTIVITY] (Linus Walleij) 2012-09-02 - 2012-09-07

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Sent off a pull request for GPIO fixes to Torvalds. * Collected some core ux500 updates and pushed them to ARM SoC for v3.7. * Debated the rôle of platform data in DT configurations, as I reviewed Nomadik I2C DT patches. * Finalized a DT patchset for the Integrator, put this into Russell's tracker. Arnd wanted CONFIG_ATAGS as part of this work to have an elegant way of #ifdef:ing out board code, Nico finalized such a patch set and Russell is contemplating it. Ran into the discussion about how to represent clocksources and clockevents in a device tree which was bound to happen since that has never been concluded in the past. * Produced an internal kernel-summit and plumbers conference report and responded to a few dozen questions from fellow workers at ST-Ericsson. * Finalized KS8695 migration to generic time and clock events, and Olof has pulled it in. File as general consolidation and/or platform deprecation - the latter option failed - what we know is that platforms using gettimeoffset() are disturbing the ARM tree and need to be augmented. * Debated the future of the too big PRCMU driver and figured out a direction, sort of. Divide and conquer, so split off pieces and push to subdrivers. We learned this antipattern: device driver writers may be tempted to organize their driver around the hardware block (which can be big, if it's an MFD!) rather than the individual functions inside it. * Finalized internal sync of the Nomadik I2C driver. * Finalized internal sync of the PL022 SPI driver. * Started internal sync of PL011 driver. === Plans === * Ongoing work on sparse IRQ for Nomadik and Ux500. * Finalize internalization of the I2C driver, review Lee's DT patches for it and integrate them too, as I get back. * 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, 9 months

1
0
0 0

[ACTIVITY] (Arnd Bergmann) 2012-08-27 - 2012-09-07

by Arnd Bergmann

=== Arnd Bergmann === * Participated in kernel summit * Co-organized ARM mini summit * Gave a presentation at Plumbers Conf about state of the ARM architecture * updated and sent patch series for ARM multiplatform kernels * merged the first set of patches for v3.7 * fixed numerous bugs found during build testing

12 years, 9 months

1
0
0 0

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

9
27
0 0

[ACTIVITY] (Anton Vorontsov) 2012-08-27 - 2012-08-31

by Anton Vorontsov

== Highlights == * Prepared and sent out deferrable timers support for timerfd API. Timefd was chosen because it's somewhat less standard (unlike posix timers), plus timerfd is less tied to the hrtimers infrastructure. http://lkml.org/lkml/2012/9/2/4 ; so far no feedback. * Started working on shrinker notifications for vmevent, this is the second part to make two-stage notifications for ulmkd (i.e. infrequent/slow polling of vmstat + faster reaction for conditions when the system is really short on memory.)

12 years, 9 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-08-27 - 2012-09-01

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Participated in the ARM workshop (mini-summit) at the kernel summit. Met and sync:ed with most kernel people I communicate with: Arnd Bergmann, Olof Johansson, Tony Lindgren, David Brown, Dmitry Torokhov, Linus Torvalds, Vincent Guittot, Thomas Gleixner and just socialized with an assortment of subsystem maintainers and especially TI and Qualcomm people. * Got irritated that the migration of clocksource and clock event is not proceeding quickly enough in the ARM tree, so wrote patches for KS8695 and CLPS711x. The KS8695 almost worked immediately, which is not so bad given that I just coded it up from the datasheet. Will proceed to root out this stuff as time permits. * Processed a part of my mail backlog and catched up with queued GPIO patches. * Finalized review of the 14 patches for the RMI4 bus in the input subsystem. === Plans === * Ongoing work on sparse IRQ for Nomadik and Ux500 * Participate in the ARM mini-summit. Hang out with kernel friends and discuss important stuff. * Finalize internalization of the I2C driver, review 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, 9 months

1
0
0 0

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

4
10
0 0

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

2
2
0 0

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

1
0
0 0

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

1
0
0 0

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

1
0
0 0

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

8
26
0 0

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

4
10
0 0

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

6
39
0 0

[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…

12 years, 9 months

2
14
0 0

[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

12 years, 9 months

1
0
0 0

[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.

12 years, 9 months

1
0
0 0

[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

12 years, 10 months

1
0
0 0

[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

12 years, 10 months

1
0
0 0

[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

12 years, 10 months

1
0
0 0

[Activity] (Omar Ramirez) Jul 23 - Aug 5 22 2012

by Omar Ramirez Luna

=== omarrmz === * [PATCH 0/3] OMAP: hwmod: reset API proposal review: IN PROGRESS. - 3/3 will be merged for 3.7, however it is not enough for remoteproc to work. - 2/3 is being discussed, had to debug some comments made by Paul that don't affect my patch because of current clock framework behavior. - 1/3 no comments received yet. * Reworked iommu OFF mode support patches with a minor update. * Mailbox runtime OFF mode: IN PROGRESS. - Saving & restoring context per mailbox instance, instead of entire bunch of registers. - This might trigger a mailbox cleanup later on. * ARMv8 - Looking at ARMv8 architecture patches, to be familiarized with the work: IN PROGRESS. * Completing HR courses: DONE. * Consolidate iommu changes into original series: NO UPDATE. - * Rebase current patches on top of Paul W changes (and accepted patches), and prepare to re-send iommu changes. * Get some time to do an omap mailbox cleanup: NO UPDATE. * Review patches from Laurent on tidspbridge: NO UPDATE. - Review a separate bug he is reporting. === Plans === * Complete mailbox changes for OFF mode support. * Keep on looking at aarch64 patches. Regards, Omar

12 years, 10 months

1
0
0 0

Question regarding kvm and its bootwrapper

by Lei Wen

Hi Peter, I'm current studying the kvm and its bootwrapper code, and find a confused point, hoping to get a answer here. First I quote words from ARM virt extension spec, it says: "When in Hyp Mode: An MSR instruction which attempts to modify the CSPR.M bits is UNPREDICTABLE, except in Debug state." While in bootwrapper, I see code would set cpu into hyp mode and launch the kernel. In kernel booting stage, it would first set the cpu mode to SVC in the start of arch/arm/kernel/head.S. And the most important is the kernel set cpu mode by directly using the MSR method which is forbidden by the virt extension spec... So here is my question: 1. Could the kernel set SVC behavior lead to any issue? 2. And could we set the cpu into SVC in bootwrapper before launch the kernel? I tried to switch to SVC before launching kernel by insert a SVC entry in hyp vector table, and copy the desired mode into spsr first then call the eret instruction. However the bootwarpper seems get hang there and I didn't figure out why... Thanks, Lei

12 years, 10 months

3
4
0 0

[PATCH v3 0/11] KGDB/KDB FIQ (NMI) debugger

by Anton Vorontsov

Hi all, I do realize that we're in the middle of the merge window. But maybe some of you will be bored enough to look into this; and no problem if you don't feel like it -- I promise to send a brand new shiny v4 after the merge window, so you won't miss a bit of this new cool stuff. :-) 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; and for convenience it is now available in the following repo: git://git.infradead.org/users/cbou/linux-nmi-kdb.git master Rationale for this patch set: 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 | 169 +------------------------ arch/arm/kernel/entry-header.S | 176 ++++++++++++++++++++++++++- arch/arm/kernel/kgdb_fiq.c | 159 ++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 76 ++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/include/mach/irqs.h | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++ drivers/tty/serial/amba-pl011.c | 13 ++ drivers/tty/serial/kgdboc.c | 9 ++ drivers/tty/serial/serial_core.c | 15 +++ include/linux/kgdb.h | 14 +++ include/linux/serial_core.h | 1 + include/linux/tty_driver.h | 1 + kernel/debug/debug_core.c | 13 +- kernel/debug/kdb/kdb_debugger.c | 4 + kernel/debug/kdb/kdb_main.c | 20 +++ 21 files changed, 591 insertions(+), 170 deletions(-) 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… -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

5
19
0 0

[PATCH 0/7] KDB: Kiosk (reduced capabilities) mode

by Anton Vorontsov

Hi all, Here is a patchset that implements "kiosk" mode for KDB debugger. The mode provides reduced set of features, so that it is no longer possible to leak sensitive data via the debugger, and not possible to change program flow in a predefined manner. The are two use-cases for the mode, one is evil, but another is quite legitimate. The evil use case is used by some (ahem) phone manufaturers that want to have a debuging facilities on a production device, but still don't want you to use the debugger to gain root access. I don't like locked phones, and I would not touch this/get my hands dirty by implementing the feature just for this evil (IMHO) use case. But there is another non-evil use case: limitting access to public devices, i.e. "kiosks", ATMs (is that too much?) or just public computers w/ guest access. I can imagine that an administrator would want to setup a kernel so that upon an oops (or a sysrq event) the kernel would enter KDB, but at the same time, he would not want to leak sensitive data from the PC by means of the debugger. There are seven patches, the first five of them are just cleanups and preparations. I believe these five patches are good even if not considering the kiosk mode. And the rest of patches actually implement the mode -- it is pretty straightforward. Note that we might impelement the same mode for KGDB stub, but so far we don't bother. Thanks! -- include/linux/kdb.h | 16 ++-- kernel/debug/kdb/kdb_bp.c | 35 ++++---- kernel/debug/kdb/kdb_main.c | 183 +++++++++++++++++++++------------------- kernel/debug/kdb/kdb_private.h | 3 +- kernel/trace/trace_kdb.c | 4 +- 5 files changed, 126 insertions(+), 115 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

5
14
0 0

[ACTIVITY] (Rajanikanth H V) 2012-07-02 to 2012-07-27

by Rajanikanth HV

==== Activity Summary ==== * Reworked DT bindings for battery type information and its dependents based on Arnd and lee's suggestion as the earlier DT bindings was exuberant and ugly w.r.t dtsi file and probe routines. * Note:battery type information are integrated in the driver, equally this helps, dependent energy management modules which are fuel-gauge and charging-algorithm * Completed Device Tree Coding for Battery-temp and Fuel-Gauge Driver * Testing in Progress with battery temperature driver as it depends on fuel-gauge From testing, it has been observed that fg or btemp interrupts are not triggered for any ab8500 events Note: mapping between Hardware IRQ and Linux Virtual IRQ is taken care * Was on sick leave for 2 days, 2012-07-23/24 ==== Plan ==== * Continue to debug interrupt events for btemp and fuel-gauge driver ==== Issues ====

12 years, 10 months

1
0
0 0

[ACTIVITY] (John Stultz) July 23-27

by John Stultz

=== Highlights === * Got back to the VOLATILE_LRU work, and got a very raw implementation to seemingly work. Hope to send it out to lkml soon. * Got my 3.6 time queue merged & sent out a few time items for tip/timers/core. * Did some work on generating better test cases for time. * Did the android upstreaming subteam weekly mail === Plans === * Send out VOLATILE_LRU work to lkml and get feedback on the approach. * Try to get the ETM driver up and running on my panda board === Issues === * None

12 years, 10 months

1
0
0 0

[ACTIVITY] (Appala Bade)

by Appala Bade

== Highlights == * LTP Driver validation Framework : IN PROGRESS 1. TI LTP-DDT(http://processors.wiki.ti.com/index.php/LTP-DDT) taken as base. 2. Modified to work on snowball platform. 3. Able to run below list of tests on snowball and those tests are part of LTP. 1.schedulr. 2. ipc. 3. syscalls. 4. memory management. 5. timers. 4. Today TI LTP-DDT having below list of driver testcases and most of the tests are depends on platform(EVM). 1.Audio(Capture and playback) 2.Ethernet 3.i2c 4.MMC 5.RTC 6.SPI 7.USB 8.v4l2 Otherthan eathenet none of the above tests are working on snowball. 5. Studying and understanding TI LTP-DDT tests implementation. == Plans == *Preparation of Testspecification for Driver validation . Thanks Appala

12 years, 10 months

1
0
0 0

[Activity] (Omar Ramirez) Jul 16 - Jul 22 2012

by Omar Ramirez Luna

=== omarrmz === === Highlights === * Iommu save and restore patches in preparation for OFF mode support: DONE - Tested them on omap4 and omap3 (with omap3-isp). - Need to decide whether to squash them with iommu series. * Mailbox runtime OFF mode: IN PROGRESS. * Recieved an email from Paul W, mentioning that he had my patches in his queue for review. NO UPDATE. * Completing TI's HR courses: IN PROGRESS. * Rebased remoteproc for-next branch and placed my patches on top of this rebase. Regards, Omar

12 years, 10 months

1
0
0 0

[ACTIVITY] (Anton Vorontsov) 2012-07-16 - 2012-07-20

by Anton Vorontsov

== Highlights == * Prepared a bunch of patches to fix KDB 'dmesg' command (the command got broken by a major logbuf rework in early 3.5 development stage). The fixes are now merged into 3.5; * Made a few last-minute fixes for the pstore/ftrace versioning code (noticed by Greg KH); * Per Steven Rostedt's comments prepared a new patch to make pstore/tracing more safe in case if we want to implement ramoops as a removable module. We no longer use tracing front-end. The patch is not urgent and doesn't bring any new features, and thus probably 3.7 material. * The fact that we don't use the tracing front-end revealed a subtle bug in ramoops module, the fix was sent to the community. Also another small bug noticed by Dan Carpenter (w/ the help of Smatch tool), the fix was also prepared and sent out. == Plans == * Finish last bits of KDB kiosk-mode patches, and send the patches out; * Check if ulmkd is still compilable w/ the recent vmevent tree (there were some API changes), then send out ulmkd announcement; * Reevaluate LMK project state, thoughtfully read the previous discussion about a new LRU list; make a plan for further steps. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

1
0
0 0

[PATCH] pstore/ram: Fix possible NULL dereference

by Anton Vorontsov

We can dereference 'cxt->cprz' if console and dump logging are disabled (which is unlikely, but still possible to do). This patch fixes the issue by changing the code so that we don't dereference przs at all, we can just calculate bufsize from console_size and record_size values. Plus, while at it, the patch improves the buffer size calculation. After Kay's printk rework, we know the optimal buffer size for console logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously, if only console logging was enabled, we would allocate unnecessary large buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging is still capable of handling buffers > LOG_LINE_MAX, it will just do multiple calls to psinfo->write). Note that I don't export the constant, since we will do even a better thing soon: we will switch console logging to a new write_buf API, which will eliminate the need for the additional buffer; and so we won't need the constant. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- fs/pstore/ram.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index b86b2b7..c34fccf 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -414,13 +414,14 @@ static int __devinit ramoops_probe(struct platform_device *pdev) cxt->pstore.data = cxt; /* - * Console can handle any buffer size, so prefer dumps buffer - * size since usually it is smaller. + * Console can handle any buffer size, so prefer LOG_LINE_MAX. If we + * have to handle dumps, we must have at least record_size buffer. And + * for ftrace, bufsize is irrelevant (if bufsize is 0, buf will be + * ZERO_SIZE_PTR). */ - if (cxt->przs) - cxt->pstore.bufsize = cxt->przs[0]->buffer_size; - else - cxt->pstore.bufsize = cxt->cprz->buffer_size; + if (cxt->console_size) + cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */ + cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize); cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL); spin_lock_init(&cxt->pstore.buf_lock); if (!cxt->pstore.buf) { -- 1.7.10.4

12 years, 10 months

2
1
0 0

[PATCH 0/2] ST-Ericsson db8500 thermal driver patch set

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> Hi all, This is the ST-Ericsson db8500 thermal dirver, here are some notes of this patch set: 1. 0001-Remove-un-necessary-variable-checking.patch is a trivial update of the thermal framework. 0002-ST-Ericsson-db8500-thermal-dirver.patch is the ST-Ericsson db8500 thermal dirver. 2. Since there is no PRCMU interface to read temperature directly, the PRCMU interrupts are used instead, and a pseudo current temperature is returned, but this works for the thermal management framework. This can be updated when the corresponding PRCMU interface is available. 3. As suggested by Vincent Guittot, the cooling device codes are seperated from thermal zone, this makes it easy to add/remove other cooling devices. CPU frequency limiting is the current cooling device. 4. The driver isn't added into device tree currently, this can be done soon if needed. hongbo.zhang (2): Remove un-necessary variable checking ST-Ericsson db8500 thermal dirver arch/arm/configs/u8500_defconfig | 4 + arch/arm/mach-ux500/board-mop500.c | 69 ++++ drivers/thermal/Kconfig | 20 ++ drivers/thermal/Makefile | 4 +- drivers/thermal/cpu_cooling.c | 3 +- drivers/thermal/db8500_cpufreq_cooling.c | 167 +++++++++ drivers/thermal/db8500_thermal.c | 476 ++++++++++++++++++++++++++ include/linux/platform_data/db8500_thermal.h | 39 +++ 8 files changed, 779 insertions(+), 3 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, 10 months

3
7
0 0

[ACTIVITY] (John Stultz) July 2-18

by John Stultz

Been terrible about sending out status this month. My apologies! === Highlights === * I'd not call it a highlight, but the leapsecond debacle has taken up the majority of my time this month. The good news is fixes are upstream as of end of last week and backports to all the seven -stable branches have been sent out as of yesterday, and nothing has blown up yet, so this issue seems just about put to bed. * Implemented a compatability shim for earlysuspend so the released Android userlands match up with upstream AOSP 3.4 and my forward proted 3.5 Android trees. This has been merged into Andrey's tree. * Got an invite to kernel summit. Plan to discuss timekeeping/leapsecond issues as well as virtual memory issues connected to vmevent changes needed for the userland-low-memory-killer work and the volatile range ashmem alternative. Also likely will discuss general android upstreaming progress. * Queued CLOCK_TICK_RATE change from the aarch64 work. Will push for 3.6 * Ran two android-kernel-subteam calls * Had meeting w/ Zach, Bero and Alexander on blueprints that are waiting for AOSP userland updates for 3.4+ kernels. * Reviewed Shawn's alarmtimer removal patch and found some issues. * Re-pinged Google devs on mmc wakelock changes. === Plans === * Vacation! I'm out of the office 19-20. * Finish digging myself out of my mail backlog * Get back to LRU_VOLATILE work. Try to finish my rough draft that I started and send it out to lkml. * Try to get the ETM driver up and running on my panda board === Issues === * Fried brain

12 years, 10 months

1
0
0 0

[PATCH] tracing: Remove unneeded checks from the stack tracer

by Anton Vorontsov

It seems that 'ftrace_enabled' flag should not be used inside the tracer functions. The ftrace core is using this flag for internal purposes, and the flag wasn't meant to be used in tracers' runtime checks. stack tracer is the only tracer that abusing the flag. So stop it from serving as a bad example. Also, there is a local 'stack_trace_disabled' flag in the stack tracer, which is never updated; so it can be removed as well. Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- kernel/trace/trace_stack.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c index d4545f4..94c2c53 100644 --- a/kernel/trace/trace_stack.c +++ b/kernel/trace/trace_stack.c @@ -33,7 +33,6 @@ static unsigned long max_stack_size; static arch_spinlock_t max_stack_lock = (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED; -static int stack_trace_disabled __read_mostly; static DEFINE_PER_CPU(int, trace_active); static DEFINE_MUTEX(stack_sysctl_mutex); @@ -115,9 +114,6 @@ stack_trace_call(unsigned long ip, unsigned long parent_ip) { int cpu; - if (unlikely(!ftrace_enabled || stack_trace_disabled)) - return; - preempt_disable_notrace(); cpu = raw_smp_processor_id(); -- 1.7.10.4

12 years, 10 months

1
0
0 0

[ACTIVITY] (Anton Vorontsov) 2012-07-09 - 2012-07-13

by Anton Vorontsov

== Highlights == * Implemented async knocking to the KDB FIQ debugger, the special $3#33 command is now used to enter the debugger. Plus prepared a new patch that makes alignment_trap asm macro self-contained; also reworked KGDB FIQ callbacks to support multi-mach kernels. This is all included in the v2 (so far there were no comments on this iteration, may be everyone is busy w/ their own patches on the merge window's eve? :-) * Addressed Steven's comments on pstore/tracing patchset and resent it. The patches are now in the linux-next tree. Some new minor enhancements (as suggested by Steven) in the works; * Fixed Dan Carpenter's comments on pstore's configurable ECC size patchset (mostly documentation). The patchset is now merged into -next; * The merge window is approaching, so needed to review/apply a bunch of battery-related patches. == Plans == * Finally update lowmemory killer blueprint; * Continue work on FIQ debugger: implement "kiosk" mode. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

1
0
0 0

[PATCH] pstore/ram: Mark ramoops_pstore_write_buf() as notrace

by Anton Vorontsov

write_buf() should be marked as notrace, otherwise it is prone to recursion. Though, yet the issue is never triggered in real life, because we run inside the function tracer, where ftrace does its own recurse protection. But it's still no good, plus soon we might switch to our own tracer ops, and then the issue will be fatal. So, let's fix it. Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- fs/pstore/ram.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 0b311bc..b86b2b7 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -32,6 +32,7 @@ #include <linux/ioport.h> #include <linux/platform_device.h> #include <linux/slab.h> +#include <linux/compiler.h> #include <linux/pstore_ram.h> #define RAMOOPS_KERNMSG_HDR "====" @@ -181,12 +182,11 @@ static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz) return len; } - -static int ramoops_pstore_write_buf(enum pstore_type_id type, - enum kmsg_dump_reason reason, - u64 *id, unsigned int part, - const char *buf, size_t size, - struct pstore_info *psi) +static int notrace ramoops_pstore_write_buf(enum pstore_type_id type, + enum kmsg_dump_reason reason, + u64 *id, unsigned int part, + const char *buf, size_t size, + struct pstore_info *psi) { struct ramoops_context *cxt = psi->data; struct persistent_ram_zone *prz = cxt->przs[cxt->dump_write_cnt]; -- 1.7.10.4

12 years, 10 months

1
0
0 0

[Activity] (Omar Ramirez) Jul 9 - Jul 15

by Omar Ramirez Luna

=== omarrmz === === Highlights === * Setting up environment to test power management, specifically for suspend/resume and OFF mode if available on 3.5-rc6. * Digging mailing list for fixes related to suspend/resume not working on Panda 4460 - Looks like there were some fixes based on 3.5-rc2 from Tero of an exiting bug only affecting 4460 that prevents the secondary CPU from correctly booting up, rebased to 3.5-rc6 to get suspend/resume working. - As a side issue while trying 4430, booting from MMC doesn't work; spent few time investigating that but given that community reports show that MMC on Panda 4430 is working abandoned the investigation. - Recent changes in MMC now force it to use DMA engine to work, minor mail exchange about that (needed to boot over MMC). * Started drafting changes for iommu and mailbox OFF mode support. * Completing TI's HR courses. * Rebased my patches floating in the mailing list to 3.5-rc6 (minor effort) Regards, Omar

12 years, 10 months

1
0
0 0

swap on eMMC and other flash

by Arnd Bergmann

We've had a discussion in the Linaro storage team (Saugata, Venkat and me, with Luca joining in on the discussion) about swapping to flash based media such as eMMC. This is a summary of what we found and what we think should be done. If people agree that this is a good idea, we can start working on it. The basic problem is that Linux without swap is sort of crippled and some things either don't work at all (hibernate) or not as efficient as they should (e.g. tmpfs). At the same time, the swap code seems to be rather inappropriate for the algorithms used in most flash media today, causing system performance to suffer drastically, and wearing out the flash hardware much faster than necessary. In order to change that, we would be implementing the following changes: 1) Try to swap out multiple pages at once, in a single write request. My reading of the current code is that we always send pages one by one to the swap device, while most flash devices have an optimum write size of 32 or 64 kb and some require an alignment of more than a page. Ideally we would try to write an aligned 64 kb block all the time. Writing aligned 64 kb chunks often gives us ten times the throughput of linear 4kb writes, and going beyond 64 kb usually does not give any better performance. 2) Make variable sized swap clusters. Right now, the swap space is organized in clusters of 256 pages (1MB), which is less than the typical erase block size of 4 or 8 MB. We should try to make the swap cluster aligned to erase blocks and have the size match to avoid garbage collection in the drive. The cluster size would typically be set by mkswap as a new option and interpreted at swapon time. 3) As Luca points out, some eMMC media would benefit significantly from having discard requests issued for every page that gets freed from the swap cache, rather than at the time just before we reuse a swap cluster. This would probably have to become a configurable option as well, to avoid the overhead of sending the discard requests on media that don't benefit from this. Does this all sound appropriate for the Linux memory management people? Also, does this sound useful to the Android developers? Would you start using swap if we make it perform well and not destroy the drives? Finally, does this plan match up with the capabilities of the various eMMC devices? I know more about SD and USB devices and I'm quite convinced that it would help there, but eMMC can be more like an SSD in some ways, and the current code should be fine for real SSDs. Arnd

12 years, 10 months

11
41
0 0

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

by Anton Vorontsov

Hi all, These patches introduce KGDB FIQ debugger support. The idea (and some code, of course) comes from Google's FIQ debugger[1]. 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 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. When you start any activity on the FIQ-enabled serial console, you'll enter KGDB and 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 testing 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" TODO: 1. alignment_trap macro uses local label, so we have to put the label into each file that use the macro. We can get rid of the label; 2. Need per-machine kgdb_arch_enable_nmi(), probably will introduce a pointer to a func; 3. Since console interrupt is actually is overtaken by NMI handler, we should make serial/uart drivers stop using TX interrupts. This my homework to think how to do it better. Currently, we would just better not use console= and kgdboc= on the same tty (but it still works, just might cause troubles if you hit TX interrupt); 4. Address any comments. :-) Thanks! -- arch/arm/Kconfig | 14 +++ 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 | 78 ++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 80 +++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/include/mach/irqs.h | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 40 +++++++ include/linux/kgdb.h | 9 ++ kernel/debug/debug_core.c | 12 +- kernel/debug/kdb/kdb_debugger.c | 4 + 15 files changed, 448 insertions(+), 167 deletions(-) p.s. [1] 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… pp.s. If anyone curious, typical NMI entry looks like this (I also executed a bit of commands): Entering kdb (current=0xc781bd60, pid 1) due to NonMaskable Interrupt @ 0xc01510d0 Pid: 1, comm: swapper CPU: 0 Not tainted (3.5.0-rc4+ #214) PC is at __delay+0x0/0xc LR is at panic+0x180/0x1b0 pc : [<c01510d0>] lr : [<c0286b64>] psr: 20000013 sp : c7823f24 ip : c7823f24 fp : c7823f38 r10: c02f35c4 r9 : 00000000 r8 : c0377988 r7 : 00000320 r6 : 000002bc r5 : 00000040 r4 : 00000000 r3 : c0020f4c r2 : 000002ce r1 : ffffffff r0 : 0000e2e1 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00093177 Table: 00004000 DAC: 00000017 Backtrace: [<c00173a4>] (dump_backtrace+0x0/0x10c) from [<c02867f4>] (dump_stack+0x18/0x1c) r6:0000000f r5:c0361d58 r4:c7823edc [<c02867dc>] (dump_stack+0x0/0x1c) from [<c001506c>] (show_regs+0x44/0x50) [<c0015028>] (show_regs+0x0/0x50) from [<c0287474>] (kdb_dumpregs+0x30/0x58) r4:c0383330 [<c0287444>] (kdb_dumpregs+0x0/0x58) from [<c00606e4>] (kdb_local.isra.5+0x354/0x5ec) r6:c0385534 r5:c7823edc r4:00000008 [<c0060390>] (kdb_local.isra.5+0x0/0x5ec) from [<c0060a28>] (kdb_main_loop+0xac/0x1bc) [<c006097c>] (kdb_main_loop+0x0/0x1bc) from [<c0063020>] (kdb_stub+0x2e0/0x3e8) r8:c0385820 r7:c0364004 r6:c0382cb4 r5:c03857c8 r4:c7823e7c [<c0062d40>] (kdb_stub+0x0/0x3e8) from [<c0059868>] (kgdb_cpu_enter.constprop.9+0x13c/0x4f8) [<c005972c>] (kgdb_cpu_enter.constprop.9+0x0/0x4f8) from [<c0059f2c>] (kgdb_handle_exception+0x8c/0xa0) [<c0059ea0>] (kgdb_handle_exception+0x0/0xa0) from [<c0008614>] (kgdb_fiq_do_handle+0x58/0x7c) r8:c0377988 r7:c7823f10 r6:ffffffff r5:c7823edc r4:c7822000 [<c00085bc>] (kgdb_fiq_do_handle+0x0/0x7c) from [<c0018df4>] (__fiq_svc+0x34/0x40) Exception stack(0xc7823edc to 0xc7823f24) 3ec0: 0000e2e1 3ee0: ffffffff 000002ce c0020f4c 00000000 00000040 000002bc 00000320 c0377988 3f00: 00000000 c02f35c4 c7823f38 c7823f24 c7823f24 c0286b64 c01510d0 20000013 3f20: ffffffff r5:20000013 r4:c01510d0 [<c02869e4>] (panic+0x0/0x1b0) from [<c0334d94>] (mount_block_root+0xe0/0x194) r3:00000000 r2:00000000 r1:c7823f50 r0:c02f355c r7:c789a000 [<c0334cb4>] (mount_block_root+0x0/0x194) from [<c0335030>] (mount_root+0xec/0x114) [<c0334f44>] (mount_root+0x0/0x114) from [<c03351c0>] (prepare_namespace+0x168/0x1bc) r7:00000013 r6:c0025c0c r5:c0351b24 r4:c0377440 [<c0335058>] (prepare_namespace+0x0/0x1bc) from [<c03349e4>] (kernel_init+0xd0/0xfc) r5:c0351b24 r4:c0351b24 [<c0334914>] (kernel_init+0x0/0xfc) from [<c0025c0c>] (do_exit+0x0/0x2d8) r5:c0334914 r4:00000000 more> kdb> md c01510d0 0xc01510d0 e2500001 8afffffd e1a0f00e e254c001 ..P...........T. 0xc01510e0 9a000033 e11c0004 0a000028 e1510004 3.......(.....Q. 0xc01510f0 e3a03000 3a00000b e16f2f14 e16fcf11 .0.....:./o...o. 0xc0151100 e042200c e3a0c001 e1a0c21c e1a02214 . B..........".. 0xc0151110 e1510002 2183300c 20511002 11b0c0ac ..Q..0.!..Q .... 0xc0151120 e1a020a2 1afffff9 e3510000 e3a02000 . ........Q.. .. 0xc0151130 01500004 31a01000 31a0f00e e3a0c102 ..P....1...1.... 0xc0151140 e1b00080 e0b11001 0a000005 31510004 ..............Q1 kdb> bp __delay Instruction(i) BP #0 at 0xc01510d0 (__delay) is enabled addr at 00000000c01510d0, hardtype=0 installed=0 kdb> go __delay Entering kdb (current=0xc781bd60, pid 1) due to Breakpoint @ 0xc01510d0 kdb> bt Stack traceback for pid 1 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper Backtrace: [<c00173a4>] (dump_backtrace+0x0/0x10c) from [<c0017804>] (show_stack+0x18/0x1c) r6:0000000f r5:c0361d58 r4:c0383330 [<c00177ec>] (show_stack+0x0/0x1c) from [<c006202c>] (kdb_show_stack+0x78/0x88) [<c0061fb4>] (kdb_show_stack+0x0/0x88) from [<c00620c0>] (kdb_bt1.isra.0+0x84/0xd8) r8:00000032 r7:00000000 r6:00000000 r5:ffffffff r4:c781bd60 [<c006203c>] (kdb_bt1.isra.0+0x0/0xd8) from [<c00623b8>] (kdb_bt+0x2a4/0x348) r7:00000001 r6:00000000 r5:c03857d0 r4:c03856fc [<c0062114>] (kdb_bt+0x0/0x348) from [<c005fdbc>] (kdb_parse+0x2cc/0x4f4) r8:00000032 r7:c03856fc r6:c02fa1f8 r5:c0383614 r4:00000009 [<c005faf0>] (kdb_parse+0x0/0x4f4) from [<c0060588>] (kdb_local.isra.5+0x1f8/0x5ec) [<c0060390>] (kdb_local.isra.5+0x0/0x5ec) from [<c0060a28>] (kdb_main_loop+0xac/0x1bc) [<c006097c>] (kdb_main_loop+0x0/0x1bc) from [<c0063020>] (kdb_stub+0x2e0/0x3e8) r8:c0385820 r7:c0364004 r6:c0382cb4 r5:c03857c8 r4:c7823de0 [<c0062d40>] (kdb_stub+0x0/0x3e8) from [<c0059868>] (kgdb_cpu_enter.constprop.9+0x13c/0x4f8) [<c005972c>] (kgdb_cpu_enter.constprop.9+0x0/0x4f8) from [<c0059f2c>] (kgdb_handle_exception+0x8c/0xa0) [<c0059ea0>] (kgdb_handle_exception+0x0/0xa0) from [<c0018ae0>] (kgdb_brk_fn+0x20/0x28) r8:c0377988 r7:00000000 r6:60000093 r5:c01510d0 r4:c7823edc [<c0018ac0>] (kgdb_brk_fn+0x0/0x28) from [<c00084f0>] (do_undefinstr+0xdc/0x1a8) [<c0008414>] (do_undefinstr+0x0/0x1a8) from [<c0013e1c>] (__und_svc+0x3c/0x60) Exception stack(0xc7823edc to 0xc7823f24) 3ec0: 0000e2e1 3ee0: ffffffff 000002ce c0020f4c 00000000 00000040 000002bc 00000320 c0377988 3f00: 00000000 c02f35c4 c7823f38 c7823f24 c7823f24 c0286b64 c01510d0 20000013 3f20: ffffffff r7:c7823f10 r6:ffffffff r5:20000013 r4:c01510d4 [<c02869e4>] (panic+0x0/0x1b0) from [<c0334d94>] (mount_block_root+0xe0/0x194) r3:00000000 r2:00000000 r1:c7823f50 r0:c02f355c r7:c789a000 [<c0334cb4>] (mount_block_root+0x0/0x194) from [<c0335030>] (mount_root+0xec/0x114) [<c0334f44>] (mount_root+0x0/0x114) from [<c03351c0>] (prepare_namespace+0x168/0x1bc) r7:00000013 r6:c0025c0c r5:c0351b24 r4:c0377440 [<c0335058>] (prepare_namespace+0x0/0x1bc) from [<c03349e4>] (kernel_init+0xd0/0xfc) r5:c0351b24 r4:c0351b24 [<c0334914>] (kernel_init+0x0/0xfc) from [<c0025c0c>] (do_exit+0x0/0x2d8) r5:c0334914 r4:00000000 kdb> kdb> ps 15 sleeping system daemon (state M) processes suppressed, use 'ps A' to see all. Task Addr Pid Parent [*] cpu State Thread Command 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper 0xc789dd60 13 2 0 0 R 0xc789df1c kworker/0:1 0xc789d580 16 2 0 0 R 0xc789d73c kworker/u:1 0xc796cd60 23 2 0 0 R 0xc796cf1c deferwq -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

2
10
0 0

[PATCH v2 0/8] KGDB/KDB FIQ (NMI) debugger

by Anton Vorontsov

Hi all, Here is v2 for the KGDB FIQ debugger, the changes include: - 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. Rationale: These patches introduce KGDB FIQ debugger support. The idea (and some code, of course) comes from Google's FIQ debugger[1]. 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 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 | 169 +------------------------ arch/arm/kernel/entry-header.S | 176 ++++++++++++++++++++++++++- arch/arm/kernel/kgdb_fiq.c | 141 +++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 76 ++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/include/mach/irqs.h | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++ include/linux/kgdb.h | 9 ++ kernel/debug/debug_core.c | 12 +- kernel/debug/kdb/kdb_debugger.c | 4 + 15 files changed, 508 insertions(+), 170 deletions(-) p.s. [1] 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… pp.s. If anyone curious, typical NMI entry looks like this (I also executed a bit of commands): Entering kdb (current=0xc781bd60, pid 1) due to NonMaskable Interrupt @ 0xc01510d0 Pid: 1, comm: swapper CPU: 0 Not tainted (3.5.0-rc4+ #214) PC is at __delay+0x0/0xc LR is at panic+0x180/0x1b0 pc : [<c01510d0>] lr : [<c0286b64>] psr: 20000013 sp : c7823f24 ip : c7823f24 fp : c7823f38 r10: c02f35c4 r9 : 00000000 r8 : c0377988 r7 : 00000320 r6 : 000002bc r5 : 00000040 r4 : 00000000 r3 : c0020f4c r2 : 000002ce r1 : ffffffff r0 : 0000e2e1 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00093177 Table: 00004000 DAC: 00000017 Backtrace: [<c00173a4>] (dump_backtrace+0x0/0x10c) from [<c02867f4>] (dump_stack+0x18/0x1c) r6:0000000f r5:c0361d58 r4:c7823edc [<c02867dc>] (dump_stack+0x0/0x1c) from [<c001506c>] (show_regs+0x44/0x50) [<c0015028>] (show_regs+0x0/0x50) from [<c0287474>] (kdb_dumpregs+0x30/0x58) r4:c0383330 [<c0287444>] (kdb_dumpregs+0x0/0x58) from [<c00606e4>] (kdb_local.isra.5+0x354/0x5ec) r6:c0385534 r5:c7823edc r4:00000008 [<c0060390>] (kdb_local.isra.5+0x0/0x5ec) from [<c0060a28>] (kdb_main_loop+0xac/0x1bc) [<c006097c>] (kdb_main_loop+0x0/0x1bc) from [<c0063020>] (kdb_stub+0x2e0/0x3e8) r8:c0385820 r7:c0364004 r6:c0382cb4 r5:c03857c8 r4:c7823e7c [<c0062d40>] (kdb_stub+0x0/0x3e8) from [<c0059868>] (kgdb_cpu_enter.constprop.9+0x13c/0x4f8) [<c005972c>] (kgdb_cpu_enter.constprop.9+0x0/0x4f8) from [<c0059f2c>] (kgdb_handle_exception+0x8c/0xa0) [<c0059ea0>] (kgdb_handle_exception+0x0/0xa0) from [<c0008614>] (kgdb_fiq_do_handle+0x58/0x7c) r8:c0377988 r7:c7823f10 r6:ffffffff r5:c7823edc r4:c7822000 [<c00085bc>] (kgdb_fiq_do_handle+0x0/0x7c) from [<c0018df4>] (__fiq_svc+0x34/0x40) Exception stack(0xc7823edc to 0xc7823f24) 3ec0: 0000e2e1 3ee0: ffffffff 000002ce c0020f4c 00000000 00000040 000002bc 00000320 c0377988 3f00: 00000000 c02f35c4 c7823f38 c7823f24 c7823f24 c0286b64 c01510d0 20000013 3f20: ffffffff r5:20000013 r4:c01510d0 [<c02869e4>] (panic+0x0/0x1b0) from [<c0334d94>] (mount_block_root+0xe0/0x194) r3:00000000 r2:00000000 r1:c7823f50 r0:c02f355c r7:c789a000 [<c0334cb4>] (mount_block_root+0x0/0x194) from [<c0335030>] (mount_root+0xec/0x114) [<c0334f44>] (mount_root+0x0/0x114) from [<c03351c0>] (prepare_namespace+0x168/0x1bc) r7:00000013 r6:c0025c0c r5:c0351b24 r4:c0377440 [<c0335058>] (prepare_namespace+0x0/0x1bc) from [<c03349e4>] (kernel_init+0xd0/0xfc) r5:c0351b24 r4:c0351b24 [<c0334914>] (kernel_init+0x0/0xfc) from [<c0025c0c>] (do_exit+0x0/0x2d8) r5:c0334914 r4:00000000 more> kdb> md c01510d0 0xc01510d0 e2500001 8afffffd e1a0f00e e254c001 ..P...........T. 0xc01510e0 9a000033 e11c0004 0a000028 e1510004 3.......(.....Q. 0xc01510f0 e3a03000 3a00000b e16f2f14 e16fcf11 .0.....:./o...o. 0xc0151100 e042200c e3a0c001 e1a0c21c e1a02214 . B..........".. 0xc0151110 e1510002 2183300c 20511002 11b0c0ac ..Q..0.!..Q .... 0xc0151120 e1a020a2 1afffff9 e3510000 e3a02000 . ........Q.. .. 0xc0151130 01500004 31a01000 31a0f00e e3a0c102 ..P....1...1.... 0xc0151140 e1b00080 e0b11001 0a000005 31510004 ..............Q1 kdb> bp __delay Instruction(i) BP #0 at 0xc01510d0 (__delay) is enabled addr at 00000000c01510d0, hardtype=0 installed=0 kdb> go __delay Entering kdb (current=0xc781bd60, pid 1) due to Breakpoint @ 0xc01510d0 kdb> bt Stack traceback for pid 1 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper Backtrace: [<c00173a4>] (dump_backtrace+0x0/0x10c) from [<c0017804>] (show_stack+0x18/0x1c) r6:0000000f r5:c0361d58 r4:c0383330 [<c00177ec>] (show_stack+0x0/0x1c) from [<c006202c>] (kdb_show_stack+0x78/0x88) [<c0061fb4>] (kdb_show_stack+0x0/0x88) from [<c00620c0>] (kdb_bt1.isra.0+0x84/0xd8) r8:00000032 r7:00000000 r6:00000000 r5:ffffffff r4:c781bd60 [<c006203c>] (kdb_bt1.isra.0+0x0/0xd8) from [<c00623b8>] (kdb_bt+0x2a4/0x348) r7:00000001 r6:00000000 r5:c03857d0 r4:c03856fc [<c0062114>] (kdb_bt+0x0/0x348) from [<c005fdbc>] (kdb_parse+0x2cc/0x4f4) r8:00000032 r7:c03856fc r6:c02fa1f8 r5:c0383614 r4:00000009 [<c005faf0>] (kdb_parse+0x0/0x4f4) from [<c0060588>] (kdb_local.isra.5+0x1f8/0x5ec) [<c0060390>] (kdb_local.isra.5+0x0/0x5ec) from [<c0060a28>] (kdb_main_loop+0xac/0x1bc) [<c006097c>] (kdb_main_loop+0x0/0x1bc) from [<c0063020>] (kdb_stub+0x2e0/0x3e8) r8:c0385820 r7:c0364004 r6:c0382cb4 r5:c03857c8 r4:c7823de0 [<c0062d40>] (kdb_stub+0x0/0x3e8) from [<c0059868>] (kgdb_cpu_enter.constprop.9+0x13c/0x4f8) [<c005972c>] (kgdb_cpu_enter.constprop.9+0x0/0x4f8) from [<c0059f2c>] (kgdb_handle_exception+0x8c/0xa0) [<c0059ea0>] (kgdb_handle_exception+0x0/0xa0) from [<c0018ae0>] (kgdb_brk_fn+0x20/0x28) r8:c0377988 r7:00000000 r6:60000093 r5:c01510d0 r4:c7823edc [<c0018ac0>] (kgdb_brk_fn+0x0/0x28) from [<c00084f0>] (do_undefinstr+0xdc/0x1a8) [<c0008414>] (do_undefinstr+0x0/0x1a8) from [<c0013e1c>] (__und_svc+0x3c/0x60) Exception stack(0xc7823edc to 0xc7823f24) 3ec0: 0000e2e1 3ee0: ffffffff 000002ce c0020f4c 00000000 00000040 000002bc 00000320 c0377988 3f00: 00000000 c02f35c4 c7823f38 c7823f24 c7823f24 c0286b64 c01510d0 20000013 3f20: ffffffff r7:c7823f10 r6:ffffffff r5:20000013 r4:c01510d4 [<c02869e4>] (panic+0x0/0x1b0) from [<c0334d94>] (mount_block_root+0xe0/0x194) r3:00000000 r2:00000000 r1:c7823f50 r0:c02f355c r7:c789a000 [<c0334cb4>] (mount_block_root+0x0/0x194) from [<c0335030>] (mount_root+0xec/0x114) [<c0334f44>] (mount_root+0x0/0x114) from [<c03351c0>] (prepare_namespace+0x168/0x1bc) r7:00000013 r6:c0025c0c r5:c0351b24 r4:c0377440 [<c0335058>] (prepare_namespace+0x0/0x1bc) from [<c03349e4>] (kernel_init+0xd0/0xfc) r5:c0351b24 r4:c0351b24 [<c0334914>] (kernel_init+0x0/0xfc) from [<c0025c0c>] (do_exit+0x0/0x2d8) r5:c0334914 r4:00000000 kdb> kdb> ps 15 sleeping system daemon (state M) processes suppressed, use 'ps A' to see all. Task Addr Pid Parent [*] cpu State Thread Command 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper 0xc781bd60 1 0 1 0 R 0xc781bf1c *swapper 0xc789dd60 13 2 0 0 R 0xc789df1c kworker/0:1 0xc789d580 16 2 0 0 R 0xc789d73c kworker/u:1 0xc796cd60 23 2 0 0 R 0xc796cf1c deferwq -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 10 months

1
8
0 0

[PATCH resend 0/3] pstore/ram: Configurable ECC size

by Anton Vorontsov

Hi all, Just a few patches left from the series that used to add configurable ECC size for pstore/ram backend. Most patches were merged into -next, and this is just a resend of the leftovers. (Note that pstore/trace patches go on top of this series.) Thanks, --- fs/pstore/ram.c | 14 +++++++------- fs/pstore/ram_core.c | 30 ++++++++++++++---------------- include/linux/pstore_ram.h | 7 ++----- 3 files changed, 23 insertions(+), 28 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 11 months

3
6
0 0

[PATCH v3 0/7] Function tracing support for pstore

by Anton Vorontsov

Hi all, 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 | 25 +++++++-- 13 files changed, 330 insertions(+), 35 deletions(-) -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 11 months

2
9
0 0

Regarding tiler : kernel(tilt-3.4)

by manjum＠ee.iitb.ac.in

Hello, We were using kernel 2.6.35 for omap4 (blazeboard), and tiler memory is tested using tiler-userspace tests (tiler_tests, memmgr_ptest and utils_test). Few tests were successfully executed. We need to test tiler on kernel-3.4, We ran tiler-userspace (branch memmgr_2.0) tests. It got failed with error: "TilerMgr_Open: No such file or directory". Can I get some pointers/links for tiler-userspace, tests? Thanks and Regards Manju

12 years, 11 months

2
1
0 0

[ACTIVITY] (Anton Vorontsov) 2012-06-25 - 2012-07-06

by Anton Vorontsov

== Highlights == * Finished versioned tracing, version tag is now written into the PRZ signature. The idea didn't cause any objections, so I guess it should be OK for merge. There is a minor (cosmetic) comment from Steven, which I'll fix and resend the series on Monday; * Finished most of the work on FIQ debugger. There is some positive feedback from Colin Cross, although the bad news is that the FIQs are "broken" on the new HW because of the hypervisor, so the debugger is useless on newest ARM SOCs. Although, it's still useful for ARMv6 SOCs, and for ARMv7 HV issue might be fixed in the future, plus part of the patches are useful for non-ARM as well (i.e. any arch that might want to invoke the debugger from an NMI); == Plans == * Make KDB console [optionally] async, and resend the FIQ/KDB patches, ask for merge; * Yet again resend pstore patches that didn't make it into -next; * Return to vmevents or pick another task? -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 11 months

1
0
0 0

[ACTIVITY] (John Stultz) June 25-29

by John Stultz

=== Highlights === * Watched a number of Google IO talks. Most interested in the the systrace tool. From initial research, it seems Jelly Bean is actually going to be based on an updated 3.0 kernel (same as ICS), meaning the 3.4 based kernels (including the merged wakelocks and other upstreamed features) won't likely be used until the Oct phone release. This may cause some pain for Linaro as changes in the 3.4 based kernel require some new userland improvements, which likely won't be available till after Oct. * Sent out updated volatile range v5 iteration. Still not much feedback. After some private discussion w/ Dave Hansen I'm looking into implementing something closer to Minchan's suggestion of a separate LRU for volatile pages. Got it sort of half working right now, and hope to sort things out soon. * LinusW reviewed the ETM patches. Had a number of suggestions for changes, including increased documentation. I'll be looking at trying to address those concerns, and resubmitting soon. * Finished newsletter update * Sent out weekly android-usptreaming email. === Plans === * Debug current LRU_VOLATILE work and hopefully get a early rough draft sent to lkml * Spend some time learning more about ETM functionality and try to make use of it so I can have some context with which to write documentation * Ping Google devs (likely at Google IO this week) about the mmc wakelock changes === Issues === GAH! HOW DID IT GET TO BE JULY ALREADY!?

12 years, 11 months

3
2
0 0

/dev/video* not showing up

by Ramakrishnan Muthukrishnan

Hi, With the latest tilt-3.4 branch, I see these messages in the kernel while booting up: [ 3.176330] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [ 3.185882] omap_vout omap_vout: 'hdmi' Display already enabled [ 3.192138] omap_vout omap_vout: 'hdmi' Display already enabled [ 3.198425] omap_vout omap_vout: Buffer Size = 3686400 [ 3.204925] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 3.211578] omap_vout omap_vout: setup_overlay failed [ 3.216949] omap_vout omap_vout: apply_changes failed [ 3.235626] omap_vout: probe of omap_vout failed with error -22 [ 3.242187] omap_vout:Could not register Video driver [ 3.253204] dmm dmm: initialized all PAT entries [ 3.414428] [drm] Enabling DMM ywrap scrolling [ 3.486267] Console: switching to colour frame buffer device 240x67 [ 3.517700] fb0: omapdrm frame buffer device [ 3.522308] drm: registered panic notifier [ 3.526733] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.533843] [drm] No driver support for vblank timestamp query. [ 3.540252] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0 [ 3.546905] ALSA device list: [ 3.550079] #0: PandaBoard [ 3.553222] #1: OMAPHDMI [ 3.793914] kjournald starting. Commit interval 5 seconds [ 3.796417] EXT3-fs (mmcblk0p2): using internal journal [ 3.798736] EXT3-fs (mmcblk0p2): recovery complete [ 3.798736] EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode [ 3.798767] VFS: Mounted root (ext3 filesystem) on device 179:2. [ 3.803009] devtmpfs: mounted [ 3.803314] Freeing init memory: 360K INIT: version 2.86 booting I don't see any /dev/video* devices listed as expected. Another observation is that, I see random kernel oops messages (they are totally random and I don't see them on reboot in some occasions). Here is the log when I see the crash: [ 3.171173] VUSB: incomplete constraints, leaving on [ 3.177368] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [ 3.186920] omap_vout omap_vout: 'hdmi' Display already enabled [ 3.193206] omap_vout omap_vout: 'hdmi' Display already enabled [ 3.199493] omap_vout omap_vout: Buffer Size = 3686400 [ 3.205993] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 3.212646] omap_vout omap_vout: setup_overlay failed [ 3.217987] omap_vout omap_vout: apply_changes failed [ 3.236663] omap_vout: probe of omap_vout failed with error -22 [ 3.243194] omap_vout:Could not register Video driver [ 3.254241] dmm dmm: initialized all PAT entries [ 3.414764] omapdrm omapdrm.0: could not remap: -12 (3) [ 3.420349] omapdrm omapdrm.0: could not map (paddr)! [ 3.453826] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.460845] [drm] No driver support for vblank timestamp query. [ 3.467132] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0 [ 3.473754] ALSA device list: [ 3.476898] #0: PandaBoard [ 3.479919] #1: OMAPHDMI [ 3.679901] kjournald starting. Commit interval 5 seconds [ 3.685791] EXT3-fs (mmcblk0p2): using internal journal [ 3.693634] EXT3-fs (mmcblk0p2): recovery complete [ 3.698699] EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode [ 3.706207] VFS: Mounted root (ext3 filesystem) on device 179:2. [ 3.716827] devtmpfs: mounted [ 3.720306] Freeing init memory: 360K INIT: version 2.86 booting Please wait: booting... Error opening /dev/fb0: No such file or directory Starting udev [ 4.311767] udevd (797): /proc/797/oom_adj is deprecated, please use /proc/797/oom_score_adj instead. [ 4.463073] ------------[ cut here ]------------ [ 4.535278] WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x7c/0x238() [ 4.692840] missing sysfs attribute operations for kobject: [ 4.719787] Modules linked in: [ 4.723663] Backtrace: [ 4.726379] [<c0012850>] (dump_backtrace+0x0/0x118) from [<c04f0e7c>] (dump_stack+0x20/0x24) [ 4.739135] r6:c0634235 r5:00000157 r4:e4a61da8 r3:00000000 [ 4.748565] [<c04f0e5c>] (dump_stack+0x0/0x24) from [<c003d274>] (warn_slowpath_common+0x5c/0x74) [ 4.760375] [<c003d218>] (warn_slowpath_common+0x0/0x74) from [<c003d348>] (warn_slowpath_fmt+0x40/0x48) [ 4.772369] r8:e4eb3590 r7:e4a20240 r6:00000000 r5:e63c0860 r4:e63b71c0 [ 4.780151] r3:00000009 [ 4.783416] [<c003d308>] (warn_slowpath_fmt+0x0/0x48) from [<c01555b4>] (sysfs_open_file+0x7c/0x238) [ 4.793548] r3:e63ac600 r2:c0634245 [ 4.797424] [<c0155538>] (sysfs_open_file+0x0/0x238) from [<c00f7634>] (__dentry_open.clone.12+0x1a0/0x2ac) [ 4.808715] r8:e4a20240 r7:00000000 r6:00000000 r5:e4e6b550 r4:e60fe310 [ 4.815673] r3:c0505400 [ 4.821899] [<c00f7494>] (__dentry_open.clone.12+0x0/0x2ac) from [<c00f8514>] (nameidata_to_filp+0x48/0x54) [ 4.832336] [<c00f84cc>] (nameidata_to_filp+0x0/0x54) from [<c0106bec>] (do_last.clone.23+0x6ac/0x6cc) [ 4.842803] r6:00000000 r5:00000000 r4:e4a61ed8 r3:00000000 [ 4.849029] [<c0106540>] (do_last.clone.23+0x0/0x6cc) from [<c0106d14>] (path_openat+0xc4/0x368) [ 4.858489] [<c0106c50>] (path_openat+0x0/0x368) from [<c01070e8>] (do_filp_open+0x3c/0x88) [ 4.867492] [<c01070ac>] (do_filp_open+0x0/0x88) from [<c00f8608>] (do_sys_open+0xe8/0x180) [ 4.876373] r7:00000001 r6:e63ff000 r5:ffffff9c r4:00000003 [ 4.882537] [<c00f8520>] (do_sys_open+0x0/0x180) from [<c00f86d0>] (sys_open+0x30/0x34) [ 4.891082] [<c00f86a0>] (sys_open+0x0/0x34) from [<c000e280>] (ret_fast_syscall+0x0/0x30) [ 4.902313] ---[ end trace 3088af14cc900807 ]--- [ 5.935852] alignment: ignoring faults is unsafe on this CPU. Defaulting to fixup mode. Remounting root file system... Caching udev devnodes The kernel commandline is this: [ 0.000000] Kernel command line: console=tty0 console=ttyO2,115200n8 earlycon=ttyO2,115200n8 earlyprintk=1 root=/dev/mmcblk0p2 rootwait rw vram=32M omapfb.vram=0:16M,1:16M omapdss.def_disp=hdmi Ramakrishnan

12 years, 11 months

6
21
0 0

[ACTIVITY] (Rajanikanth H V) 2012-06-25 to 2012-06-29

by Rajanikanth HV

==== Activity Summary ==== * Completed DT binding on btemp and fuel guage driver with documentation - Obtained review comments from lee jones * Got the battery interface ready for Snowball V11 board - Board is booting with external battery power - Currently using "Sonyericsson BST41" Battery type for testing * Observed kernel crash at gpadc call with battery interface on first iteration of testing ==== Plan ==== * Work on review comments * Complete the testing and bug fix of btemp and "fuel guage" driver using battery interface ==== Issues ==== 2012-07-05 : I will be on leave

12 years, 11 months

1
0
0 0

tilt-tracking branch on OMAP4 Blaze

by Ramakrishnan Muthukrishnan

Hi, I am trying to boot the tilt-tracking branch of the TI OMAP kernel git repository. The silicon is OMAP4430 ES2.1 on TI Blaze platform. I see a kernel crash while booting. The logs also show that the HDMI GPIOs requests are not successful. What I am looking for is a fairly recent kernel on which I can base the rest of the userspace (media) application on. Any help on which branch to look for, will be greatly appreciated. Thanks Ramakrishnan [ 4.836944] Console: switching to colour frame buffer device 240x67 [ 4.892089] sdp4430_panel_enable_hdmi: Cannot request HDMI GPIOs [ 4.898437] omapdss HDMI error: failed to enable GPIO's [ 4.903991] omapdss error: failed to power on [ 4.908599] omapfb omapfb: Failed to enable display 'hdmi' [ 4.914398] omapfb omapfb: failed to initialize default display [ 4.921325] omapfb omapfb: failed to setup omapfb [ 4.926330] omapfb: probe of omapfb failed with error -16 [ 4.932586] VANA: incomplete constraints, leaving on [ 4.938934] VDAC: incomplete constraints, leaving on [ 4.945983] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:03 UTC (946684803) [ 4.954620] ALSA device list: [ 4.957733] #0: SDP4430 [ 4.960540] #1: OMAPHDMI [ 4.997589] Division by zero in kernel. [ 4.997619] Backtrace: [ 4.997650] [<c0012d4c>] (dump_backtrace+0x0/0x118) from [<c04ec94c>] (dump_stack+0x20/0x24) [ 4.997650] r6:00000000 r5:f0800000 r4:ee21dd80 r3:00000000 [ 4.997680] [<c04ec92c>] (dump_stack+0x0/0x24) from [<c0012ea8>] (__div0+0x20/0x28) [ 4.997711] [<c0012e88>] (__div0+0x0/0x28) from [<c0259b14>] (Ldiv0+0x8/0x10) [ 4.997772] [<c0287348>] (cfb_imageblit+0x0/0x46c) from [<c0280828>] (soft_cursor+0x1b8/0x1c4) [ 4.997772] [<c0280670>] (soft_cursor+0x0/0x1c4) from [<c02801b0>] (bit_cursor+0x43c/0x44c) [ 4.997802] [<c027fd74>] (bit_cursor+0x0/0x44c) from [<c027a920>] (fb_flashcursor+0x108/0x124) [ 4.997802] [<c027a818>] (fb_flashcursor+0x0/0x124) from [<c00562e4>] (process_one_work+0x274/0x420) [ 4.997833] [<c0056070>] (process_one_work+0x0/0x420) from [<c005681c>] (worker_thread+0x1bc/0x2bc) [ 4.997863] [<c0056660>] (worker_thread+0x0/0x2bc) from [<c005c93c>] (kthread+0x98/0xa4) [ 4.997863] [<c005c8a4>] (kthread+0x0/0xa4) from [<c0041300>] (do_exit+0x0/0x790) [ 4.997894] r7:00000013 r6:c0041300 r5:c005c8a4 r4:ee093ed8 [ 5.192901] Division by zero in kernel. [ 5.192901] Backtrace:

12 years, 11 months

4
8
0 0

tilt-3.4 kernel, v4l2 display driver

by Martin Ertsås

Hi. From tilt-3.3, the v4l2 display drivers were dependent on: ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 in 3.4, this has changed to ARCH_OMAP2 || ARCH_OMAP3 Is there a reason omap4 and omap5 have been removed? Has something broken, or is it just something missed when merging from upstream? Can't find any commit about that change, only commit there is from ARCH_OMAP24XX || ARCH_OMAP34XX to what it is now, which I guess was during the merge or something. Best regards Martin

12 years, 11 months

2
3
0 0

[ACTIVITY] (Anton Vorontsov) 2012-06-18 - 2012-06-22

by Anton Vorontsov

== Highlights == * Got KDB running on the Versatile-PB board (in QEMU), plus got FIQs somewhat working. Feature-wise, the only thing left to do is to get KDB to work in the FIQ context, and then we can just clean up the code here and there, and submit it; * Early probing for pstore merged into -next; * Half of pstore ECC improvements merged into -next, another half is still pending; * I implemented versioned tracing as a separate persistent ram zone for the control data, but I didn't like it, it was ugly. I think I can do it better: something like persistent_ram_reduce(), a new call that would reduce the current buffer, leaving space for the control data; * vmevents discussion continues on the lkml, It seems that Minchan's idea is not as easy as it seemed to be, there are many corner cases and limitations. And I still don't actually follow how exactly having a separate LRU would help obtaining statistics. == Plans == * Continue work on FIQ debugger. * Resend pstore patches that didn't make it into -next. There are just a few left. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 11 months

1
0
0 0

[ACTIVITY] (Dong Aisheng) June-18-June-20

by Dong Aisheng

=== Highlights === * Continued to review Shawn's big patch series adding irqdomain and sparse irq support for IMX platforms. Had some different options with Shawn on the implementation, i pointed out some drawbacks of his implementation and sent out a patch to describe my idea, but Shawn did not agree with my idea although i'm still not very convinced by his reasons. Currently we still use the original way. * sent two irq core minor fix and clean up patches * sent patch of: reform prom_update_property function which can simply the using and remove a lot duplicated code, acked by maintainer already. * reviewed Shawn's ARM: mxs: store mac address read from OTP in device tree patch. gave some comments and suggested him to rebase his patch on my of: reform prom_update_property patch. * Reviewed ASoC: dmaengine-pcm: Add support for querying stream position from DMA driver. The current imx/mxs dma driver still does not support tx_status querying for cyclic dma transfer, will add the support later when have time. * reviewed and sent a pinctrl-imx fix patch. Asked Linus to merge it for 3.5 kernel.

12 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel