The only difference between schedule_delayed_work[_on]() and
queue_delayed_work[_on]() is the workqueue, work is scheduled on. We may need to
modify the delay for works queued with schedule_delayed_work[_on]() calls and
thus adding these helpers.
First users of these new helpers is cpufreq governors which need to modify the
delay for its works.
Cc: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
include/linux/workqueue.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 2b58905..864c2b3 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -412,6 +412,7 @@ extern bool schedule_delayed_work_on(int cpu, struct delayed_work *work,
extern bool schedule_delayed_work(struct delayed_work *work,
unsigned long delay);
extern int schedule_on_each_cpu(work_func_t func);
+
extern int keventd_up(void);
int execute_in_process_context(work_func_t fn, struct execute_work *);
@@ -465,6 +466,11 @@ static inline long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg);
#endif /* CONFIG_SMP */
+#define mod_scheduled_delayed_work_on(cpu, dwork, delay) \
+ mod_delayed_work_on(cpu, system_wq, dwork, delay)
+#define mod_scheduled_delayed_work(dwork, delay) \
+ mod_delayed_work(system_wq, dwork, delay)
+
#ifdef CONFIG_FREEZER
extern void freeze_workqueues_begin(void);
extern bool freeze_workqueues_busy(void);
--
1.7.12.rc2.18.g61b472e
When a cpu goes to a deep idle state where its local timer is shutdown,
it notifies the time framework to use the broadcast timer instead.
Unfortunately, the broadcast device could wake up any CPU, including an
idle one which is not concerned by the wake up at all.
This implies, in the worst case, an idle CPU will wake up to send an IPI
to another idle cpu.
This patch solves this by setting the irq affinity to the cpu concerned
by the nearest timer event, by this way, the CPU which is wake up is
guarantee to be the one concerned by the next event and we are safe with
unnecessary wakeup for another idle CPU.
As the irq affinity is not supported by all the archs, a flag is needed
to specify which clocksource can handle it.
Daniel Lezcano (3):
time : pass broadcast parameter
time : set broadcast irq affinity
ARM: nomadik: add dynamic irq flag to the timer
Viresh Kumar (1):
ARM: timer-sp: Set dynamic irq affinity
arch/arm/common/timer-sp.c | 3 ++-
drivers/clocksource/nomadik-mtu.c | 3 ++-
include/linux/clockchips.h | 1 +
kernel/time/tick-broadcast.c | 40 +++++++++++++++++++++++++++++--------
4 files changed, 37 insertions(+), 10 deletions(-)
--
1.7.9.5
Hi,
Please find a link[1] to some of the things we plan to discuss and
work on in Hong Kong next week.
If you're interested in some of these topics and are attending in
person, please come and say hello.
See you in Hong Kong!
Regards,
Amit
-----------------------------------------------
PMWG Tech Lead, Linaro
[1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/HK_LCA2013
This patch series adds support for DRM FIMD DT for Exynos4 DT Machines,
specifically for Exynos4412 SoC.
changes since v5:
- renamed the fimd binding documentation file name as "samsung.fimd.txt",
since it not only talks about exynos display controller but also about
previous samsung display controllers.
- rephrased an abmigious statement about the interrupt combiner in the
fimd binding documentation as pointed out by
Sachin Kamat <sachin.kamat.linaro.org>
changes since v4:
- moved the fimd binding documentation to Documentation/devicetree/bindings/video/
as suggested by Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com>
- added more fimd compatiblity strings in fimd documentation as
discussed at https://patchwork.kernel.org/patch/2144861/ with
Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com> and
Tomasz Figa <tomasz.figa(a)gmail.com>
- modified compatible string for exynos4 fimd as "exynos4210-fimd"
exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/2144861/
- documented more about the interrupt combiner and their order as
suggested by Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com>
changes since v3:
- rebased on
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlo…
changes since v2:
- added alias to 'fimd@11c00000' node
(reported by: Rahul Sharma <r.sh.open(a)gmail.com>)
- removed 'lcd0_data' node as there was already a similar node lcd_data24
(reported by: Jingoo Han <jg1.han(a)samsung.com>
- replaced spaces with tabs in display-timing node
changes since v1:
- added new patch to add FIMD DT binding Documentation
- removed patch enabling SAMSUNG_DEV_BACKLIGHT and SAMSUNG_DEV_PMW
for mach-exynos4 DT
- added 'status' property to fimd DT node
Is based on branch "for-next-next"
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlo…
Sachin Kamat (1):
ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC
Vikas Sajjan (4):
ARM: dts: Add FIMD node to exynos4
ARM: dts: Add FIMD node and display timing node to
exynos4412-origen.dts
ARM: dts: add FIMD AUXDATA node entry for exynos4 DT
ARM: dts: Add FIMD DT binding Documentation
.../devicetree/bindings/video/samsung-fimd.txt | 54 ++++++++++++++++++++
arch/arm/boot/dts/exynos4.dtsi | 7 +++
arch/arm/boot/dts/exynos4412-origen.dts | 22 ++++++++
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 14 +++++
arch/arm/mach-exynos/mach-exynos4-dt.c | 2 +
5 files changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt
--
1.7.9.5
My first post in to the mailing list.
Deep power idle state is nothing but CPU power domain off. Its not impossible but would require some hw change.
If kernel is aware of a CPU being in power off state, can we first do a CPU wakeup before issuing SGI.
The wakeup routine has to be implemented by SoC provider as it will be different for each vendor.
Regds
Shakti
Sent from my Nokia Lumia 920
________________________________
From: Santosh Shilimkar<mailto:santosh.shilimkar@ti.com>
Sent: 2/26/2013 10:00 PM
To: Daniel Lezcano<mailto:daniel.lezcano@linaro.org>
Cc: jacob.jun.pan(a)linux.intel.com<mailto:jacob.jun.pan@linux.intel.com>; Russell King - ARM Linux<mailto:linux@arm.linux.org.uk>; linus.walleij(a)stericsson.com<mailto:linus.walleij@stericsson.com>; linux-pm(a)vger.kernel.org<mailto:linux-pm@vger.kernel.org>; viresh.kumar(a)linaro.org<mailto:viresh.kumar@linaro.org>; patches(a)linaro.org<mailto:patches@linaro.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; linaro-kernel(a)lists.linaro.org<mailto:linaro-kernel@lists.linaro.org>; linux-arm-kernel(a)lists.infradead.org<mailto:linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/4] time: dynamic irq affinity
On Wednesday 27 February 2013 03:47 AM, Daniel Lezcano wrote:
> When a cpu goes to a deep idle state where its local timer is shutdown,
> it notifies the time framework to use the broadcast timer instead.
>
> Unfortunately, the broadcast device could wake up any CPU, including an
> idle one which is not concerned by the wake up at all.
>
> This implies, in the worst case, an idle CPU will wake up to send an IPI
> to another idle cpu.
>
> This patch solves this by setting the irq affinity to the cpu concerned
> by the nearest timer event, by this way, the CPU which is wake up is
> guarantee to be the one concerned by the next event and we are safe with
> unnecessary wakeup for another idle CPU.
>
> As the irq affinity is not supported by all the archs, a flag is needed
> to specify which clocksource can handle it.
>
Not completely related to this series but there is another
issue where this local timer not wakeup capable hurts. So
far we are discussing only the timer related future events
which are known and can be programmed with broadcast device.
But think of the scenario's where we need to send asynchronous
IPIs to CPUs to do some work. e.g generic_exec_single().
If the CPU which is suppose to be available after IPI call
is in deep low power state, then the IPI(implemented on ARM)
isn't effective. In CPU off idle modes, a GIC SGI will not wake
the CPU and hence a special wakeup is needed to bring out
those CPUs out of idle. This special wakeup is handled
by broad-cast timer in case of CPUIDLE.
In short what I mean is, you need to have IPI which
can wakeup CPUs from any deep idle power state to address
above. Has anybody thought of this one ?
Regards,
Santosh
P.S: Time and again it proves that making the local timer wakeup
capable solves the issue.
_______________________________________________
linaro-kernel mailing list
linaro-kernel(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-kernel
Hi All,
I am new on this mailing list, I browsed archive against vmcore but
got no hit so the question here.
I am running
./Foundation_v8pkg/Foundation_v8 \
--image ./img-foundation.axf \
--block-device ./vexpress64-openembedded_sdk-armv8_20130127-242.img \
--network=nat
That gives
Linux genericarmv8 3.8.0-1-linaro-vexpress64 #1ubuntu1~ci+130127041142
SMP Sun Jan 27 04:15:58 UTC 2013 aarch64 GNU/Linux
root@genericarmv8:/usr#
I am doing some linux crashdump analysis tools, and I'd like to
prepare the future.
At the moment I am not sure how to obtain an aa64 linux crashdump
(vmcore), as I got no HW then no distro.
I was wondering, is it possible to send a signal to the Foundation_v8
and then got a copy of the guest emulated main memory ? along with a
savestate per cpu ?
And to make this usable, is there a way to obtain the vmlinux (and
possibly modules) a.out non stripped with debuginfos that was used to
obtain the img.axf (abd the modules in the .img if any)
If this is not doable with file on the server used during the build of
./img-foundation.axf and
./vexpress64-openembedded_sdk-armv8_20130127-242.img
then may be I got to expliclty build my own .axf .img and keep the
debuginfo from this build.
Any advises appreciated.
Thank you for the linaro that booted straightaway.
Cheers,
Phi
Hi Tixy,
Yes, I have tried both the config in the release notes as well as
configurations to boot A7.
The configurations to boot A7 hang while executing the BOOTSCRIPT.
The release note configurations get past that state, boot up the kernel and
hang as shown in this thread.
As a first step, I am just trying to get the release note configuration
working without the hang.
Thanks
Dinesh
On Tue, Feb 26, 2013 at 9:43 AM, Jon Medhurst (Tixy) <tixy(a)linaro.org>wrote:
> On Tue, 2013-02-26 at 09:24 -0800, D D wrote:
> > Thanks Tixy, I tried 0x0032F003, but still seeing the same hang.
> > Looks like 0x0032F003 powers down the non boot cluster (in this case
> > A7), while I wanted to try running with the A7s online. That was the
> > reason why I was trying to boot with 0x00320003.
>
> So you have other config changes to get the board booting on A7? I've
> never tried to do that.
>
> Does the config produced by our release notes work for you? (Which will
> boot on the A15's.)
>
> I'm trying to understand if we're debugging a problem with the Linaro
> release, or debugging whatever modified setup you have.
>
> --
> Tixy
>
>
>
Lorenzo,
Looking in the cpuidle code in Linaro's 13.01 kernel, there are only two idle states supported in the cpuidle/arm_big_little.c, one is WFI, the other is C1. So to have more than these 2 idle states supported on a SoC, it looks like I have to create SoC specific CPU idle driver to replace the arm_big_little.c. Is this the intended design? It would be better if there is a way the arm_big_little.c can support SoC specific idle sets, via device tree maybe?
Eric Huang