linaro-kernel November 2013

linaro-kernel@lists.linaro.org

85 participants
204 discussions

by Alex Shi

When I read the runnable load avg code, I found the task's avg.load_avg_contrib mainly updated in enqueue/dequeue, and the 'curr' task in sched_tick. So, if a sleep long time task is waked/added and kept on a cpu, but the task is never be the 'curr' in sched_tick. Then the task's load contrib will never be updated and keep small. what I missed? or Is it really? -- Thanks Alex

11 years, 5 months

[PATCH V2 0/2] cpufreq: suspend governors during s2r/hibernation

by Viresh Kumar

This patchset adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for handling suspend/resume of cpufreq governors. This is required for early suspend and late resume of governors. There are multiple problems that are fixed by this patch: - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board wasn't working well with suspend/resume as calls for removing non-boot CPUs was turning out into a call to drivers ->target() which then tries to play with regulators. But regulators and their I2C bus were already suspended and this resulted in a failure. This is why we need a PM notifier here. - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where tunables configuration for clusters/sockets with non-boot CPUs was getting lost after suspend/resume, as we were notifying governors with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so deallocating memory for tunables. This was earlier sent here: https://lkml.org/lkml/2013/11/15/107 V1->V2: - Used direct callbacks from dpm_{suspend|resume}_noirq() for suspending/resuming govenors instead of doing that with help of PM notifiers. - Patch 2/2: Switching to the desirable frequency before suspending the governors. Viresh Kumar (2): cpufreq: suspend governors on system suspend/hibernate cpufreq: Change freq before suspending governors drivers/base/power/main.c | 3 ++ drivers/cpufreq/cpufreq.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/cpufreq.h | 5 +++ 3 files changed, 87 insertions(+) -- 1.7.12.rc2.18.g61b472e

11 years, 5 months

[PATCH] i2c: omap: raw read and write endian fix

by Taras Kondratiuk

From: Victor Kamensky <victor.kamensky(a)linaro.org> All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky <victor.kamensky(a)linaro.org> Signed-off-by: Taras Kondratiuk <taras.kondratiuk(a)linaro.org> --- Posting this as a saparate patch out of RFC series. RFC: http://patchwork.ozlabs.org/patch/291726/ Only minor comment change is done since RFC patch. Based on v3.13-rc1 drivers/i2c/busses/i2c-omap.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d76228d..90dcc2e 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -266,13 +266,13 @@ static const u8 reg_map_ip_v2[] = { static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev, int reg, u16 val) { - __raw_writew(val, i2c_dev->base + + writew_relaxed(val, i2c_dev->base + (i2c_dev->regs[reg] << i2c_dev->reg_shift)); } static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg) { - return __raw_readw(i2c_dev->base + + return readw_relaxed(i2c_dev->base + (i2c_dev->regs[reg] << i2c_dev->reg_shift)); } @@ -1162,9 +1162,9 @@ omap_i2c_probe(struct platform_device *pdev) * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2. * On omap1/3/2 Offset 4 is IE Reg the bit [15:14] is 0 at reset. * Also since the omap_i2c_read_reg uses reg_map_ip_* a - * raw_readw is done. + * readw_relaxed is done. */ - rev = __raw_readw(dev->base + 0x04); + rev = readw_relaxed(dev->base + 0x04); dev->scheme = OMAP_I2C_SCHEME(rev); switch (dev->scheme) { -- 1.7.9.5

11 years, 5 months

[PATCH V3 0/6] cpufreq: suspend early/resume late

by Viresh Kumar

This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling suspend/resume of cpufreq governors and core. This is required for early suspend and late resume of governors and cpufreq core. There are multiple problems that are fixed by this patch: - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board wasn't working well with suspend/resume as calls for removing non-boot CPUs was turning out into a call to drivers ->target() which then tries to play with regulators. But regulators and their I2C bus were already suspended and this resulted in a failure. Many platforms have such problems, samsung, tegra, etc.. They solved it with driver specific PM notifiers where they used to disable their driver's ->target() routine. Most of these are updated in this patchset to use new infrastructure. - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where tunables configuration for clusters/sockets with non-boot CPUs was getting lost after suspend/resume, as we were notifying governors with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so deallocating memory for tunables. This is also fixed with this patch as don't allow any operation on Governors during suspend/resume now. So to solve these issues we introduce early suspend and late resume callbacks which would remove need of cpufreq drivers to implement PM notifiers to disable transition after suspend and before resume. @Nishanth: Can you please test V2 as well and confirm that suspend_noirq() doesn't work for you. I am sure it will not, but would be better if you confirm that. Viresh Kumar (6): cpufreq: suspend governors on system suspend/hibernate cpufreq: call driver's suspend/resume for each policy cpufreq: Implement cpufreq_generic_suspend() cpufreq: exynos: Use cpufreq_generic_suspend() cpufreq: s5pv210: Use cpufreq_generic_suspend() cpufreq: Tegra: Use cpufreq_generic_suspend() drivers/base/power/main.c | 5 ++ drivers/cpufreq/cpufreq.c | 133 +++++++++++++++++++++----------------- drivers/cpufreq/exynos-cpufreq.c | 97 ++------------------------- drivers/cpufreq/s5pv210-cpufreq.c | 49 +------------- drivers/cpufreq/tegra-cpufreq.c | 54 ++-------------- include/linux/cpufreq.h | 6 ++ 6 files changed, 99 insertions(+), 245 deletions(-) -- 1.7.12.rc2.18.g61b472e

11 years, 5 months

arm-soc boot: 30 pass, 0 fail (v3.13-rc1-51-g9f6f9eb)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: arm-soc Git describe: v3.13-rc1-51-g9f6f9eb Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 27.8 sec omap3-beagle-xm PASS: 0 min 51.0 sec am335x-bone PASS: 0 min 26.6 sec omap4-panda PASS: 1 min 3.5 sec omap4-panda-es PASS: 1 min 5.7 sec omap3-tobi,3730storm PASS: 0 min 20.6 sec omap3-tobi,3530overo PASS: 0 min 22.0 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 18.1 sec imx6dl-wandboard,wand-solo PASS: 0 min 18.2 sec imx6q-wandboard PASS: 0 min 15.4 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 22.2 sec armada-370-mirabox PASS: 0 min 20.0 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 32.3 sec tegra30-beaver PASS: 0 min 14.2 sec am335x-boneblack PASS: 0 min 34.7 sec omap3-beagle-xm PASS: 0 min 52.1 sec sun7i-a20-cubieboard2 PASS: 0 min 12.9 sec armada-370-mirabox PASS: 0 min 20.6 sec omap4-panda PASS: 1 min 2.0 sec omap4-panda-es PASS: 1 min 1.0 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec am335x-bone PASS: 0 min 33.5 sec imx6q-wandboard PASS: 0 min 16.8 sec omap3-tobi,3730storm PASS: 0 min 19.7 sec imx6dl-wandboard,wand-dual PASS: 0 min 17.9 sec omap3-tobi,3530overo PASS: 0 min 20.1 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 27.7 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.4 sec

11 years, 5 months

next boot: 30 pass, 0 fail (next-20131127)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20131127 Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 27.8 sec omap3-beagle-xm PASS: 0 min 53.6 sec am335x-bone PASS: 0 min 26.6 sec omap4-panda PASS: 1 min 5.3 sec omap4-panda-es PASS: 1 min 1.7 sec omap3-tobi,3730storm PASS: 0 min 20.6 sec omap3-tobi,3530overo PASS: 0 min 21.9 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 18.1 sec imx6dl-wandboard,wand-solo PASS: 0 min 18.3 sec imx6q-wandboard PASS: 0 min 16.6 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.9 sec armada-370-mirabox PASS: 0 min 20.1 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 28.5 sec tegra30-beaver PASS: 0 min 14.2 sec am335x-boneblack PASS: 0 min 34.7 sec omap3-beagle-xm PASS: 0 min 52.8 sec sun7i-a20-cubieboard2 PASS: 0 min 13.1 sec armada-370-mirabox PASS: 0 min 20.5 sec omap4-panda PASS: 1 min 2.1 sec omap4-panda-es PASS: 1 min 3.7 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec am335x-bone PASS: 0 min 33.4 sec imx6q-wandboard PASS: 0 min 17.0 sec omap3-tobi,3730storm PASS: 0 min 19.7 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.8 sec omap3-tobi,3530overo PASS: 0 min 20.1 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 28.9 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.4 sec

11 years, 5 months

[PATCH] ARM:EXYNOS:Enabled AUTO_ZRELADDR and ARM_PATCH_PHYS_VIRT

by panchaxari

Introduction of ARM_PATCH_PHYS_VIRT as default would make the platform to support dynamic reallocation of memory and also allows phy-to-virt and virt-to-phy translations functions at boot time and module loading time. AUTO_ZRELADDR would introduce address calculation of decompressed kernel from the location of zImage in RAM. EXYNOS platforms mostly uses Onenand which was developed as replacement of NOR devices, it is developed such that it plugs directly into existing NOR interface. OneNAND supports NOR interfaces also for backward compatibility with NOR supporting system. Below explaination by Russel in LKML clears the concept of AUTO_ZRELADDR and ARM_PATCH_PHYS_VIRT AUTO_ZRELADDR=n ZBOOT_ROM=n => fixed address for decompressed kernel image to be decompressed to from zreladdr make variable, decompressor can be loaded to any RAM address. AUTO_ZRELADDR=y ZBOOT_ROM=n => address for decompressed kernel calculated from location of zImage in RAM, decompressor must be loaded to the correct place in RAM and must always copy itself out of the way prior to decompressing. AUTO_ZRELADDR=n ZBOOT_ROM=y => fixed address for decompressed kernel image to be decompressed to from zreladdr make variable, decompressor can be loaded to any RAM address which doesn't overlap its BSS segment, or decompressor programmed into read-only memory at the address to which it was compiled. AUTO_ZRELADDR=y ZBOOT_ROM=y => invalid (think about it - this results in a zImage which is built to be run from read-only memory, and try to write the decompressed image into that read-only memory.) This has nothing to do with XIP or not - XIP is a completely separate story, and if you're building an XIP kernel you're not using the decompressor (so AUTO_ZRELADDR and ZBOOT_ROM don't even feature.) Neither does the dynamic code patching stuff like ARM_PATCH_PHYS_VIRT. ARM_PATCH_PHYS_VIRT has no bearing on AUTO_ZRELADDR or ZBOOT_ROM; that is a property of the decompressed kernel image itself, and while your decompressor may restrict where it can decompress the kernel image to, the decompressed image itself remains free of those dependencies (and eg, can be turned into a uImage with the appropriate load address for other platforms.) As I've said in the past, what I'd _like_ to see is that ARM_PATCH_PHYS_VIRT be enabled for everything irrespective of any other configuration, and we're just left with AUTO_ZRELADDR / ZBOOT_ROM to worry about. The overhead from the P:V patching is soo small that it's not really worth even having the option in the general case - the only time when P:V patching doesn't work is with non-linear translations found on some sparsemem platforms. But... one thing to note is that it _is_ common to load the decompressor at a _different_ address to that where the kernel ultimately ends up residing to avoid the additional copy in the decompressor. My experience shows that this is quite common on the platforms I had supplied. This means that if we default to AUTO_ZRELADDR for !ZBOOT_ROM, we end up having to have developers change their uboot setups to avoid unexpected results. panchaxari (1): ARM:EXYNOS:Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) -- 1.7.10.4

11 years, 5 months

mainline boot: 30 pass, 0 fail (v3.13-rc1-141-g8ae516a)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: mainline Git describe: v3.13-rc1-141-g8ae516a Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 27.9 sec omap3-beagle-xm PASS: 0 min 51.9 sec am335x-bone PASS: 0 min 26.6 sec omap4-panda PASS: 1 min 4.2 sec omap4-panda-es PASS: 1 min 0.7 sec omap3-tobi,3730storm PASS: 0 min 23.5 sec omap3-tobi,3530overo PASS: 0 min 21.8 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 16.9 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.9 sec imx6dl-wandboard,wand-solo PASS: 0 min 18.3 sec imx6q-wandboard PASS: 0 min 16.6 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.9 sec armada-370-mirabox PASS: 0 min 19.9 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 28.2 sec tegra30-beaver PASS: 0 min 17.5 sec am335x-boneblack PASS: 0 min 34.7 sec omap3-beagle-xm PASS: 0 min 47.0 sec sun7i-a20-cubieboard2 PASS: 0 min 13.0 sec armada-370-mirabox PASS: 0 min 20.5 sec omap4-panda PASS: 1 min 2.5 sec omap4-panda-es PASS: 0 min 59.3 sec armada-xp-openblocks-ax3-4 PASS: 0 min 23.0 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec am335x-bone PASS: 0 min 33.4 sec imx6q-wandboard PASS: 0 min 16.9 sec omap3-tobi,3730storm PASS: 0 min 19.7 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.7 sec omap3-tobi,3530overo PASS: 0 min 22.9 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 31.5 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.3 sec

11 years, 5 months

queue boot: 30 pass, 0 fail (v3.12.1-116-g8f4344e)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: queue Git describe: v3.12.1-116-g8f4344e Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 27.3 sec omap3-beagle-xm PASS: 0 min 48.5 sec am335x-bone PASS: 0 min 26.1 sec omap4-panda PASS: 1 min 6.0 sec omap4-panda-es PASS: 1 min 6.2 sec omap3-tobi,3730storm PASS: 0 min 20.2 sec omap3-tobi,3530overo PASS: 0 min 21.4 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.2 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.1 sec imx6q-wandboard PASS: 0 min 14.8 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 22.0 sec armada-370-mirabox PASS: 0 min 19.9 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 28.1 sec tegra30-beaver PASS: 0 min 14.1 sec am335x-boneblack PASS: 0 min 34.4 sec omap3-beagle-xm PASS: 0 min 51.2 sec sun7i-a20-cubieboard2 PASS: 0 min 12.9 sec armada-370-mirabox PASS: 0 min 20.5 sec omap4-panda PASS: 1 min 1.3 sec omap4-panda-es PASS: 1 min 4.0 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.3 sec am335x-bone PASS: 0 min 33.2 sec imx6q-wandboard PASS: 0 min 15.7 sec omap3-tobi,3730storm PASS: 0 min 22.1 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec omap3-tobi,3530overo PASS: 0 min 20.1 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 33.5 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.3 sec

11 years, 5 months

queue boot: 23 pass, 0 fail (v3.11.9-36-g375290a)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: queue Git describe: v3.11.9-36-g375290a Full Report =========== omap2plus_defconfig ------------------- omap3-beagle-xm PASS: 0 min 50.0 sec am335x-bone PASS: 0 min 26.5 sec omap4-panda PASS: 1 min 5.4 sec omap4-panda-es PASS: 1 min 7.7 sec omap3-tobi,3730storm PASS: 0 min 24.2 sec omap3-tobi,3530overo PASS: 0 min 21.7 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 15.4 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 15.9 sec imx6dl-wandboard,wand-solo PASS: 0 min 15.6 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.8 sec armada-370-mirabox PASS: 0 min 19.9 sec multi_v7_defconfig ------------------ tegra30-beaver PASS: 0 min 17.2 sec omap3-beagle-xm PASS: 0 min 50.3 sec armada-370-mirabox PASS: 0 min 20.5 sec am335x-bone PASS: 0 min 33.6 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.2 sec omap4-panda PASS: 1 min 2.3 sec omap4-panda-es PASS: 1 min 17.2 sec omap3-tobi,3730storm PASS: 0 min 22.7 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.4 sec omap3-tobi,3530overo PASS: 0 min 20.2 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.2 sec

11 years, 5 months

← Newer
1
2
3
4
5
6
7
8
...
21
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel November 2013