On 04/29/2015 02:47 AM, Juri Lelli wrote:
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
Did preceding commits' function support in juno tree, or they were replaced by other commits? Is juno cpuidle driver happy without them?
As said, I'm not sure about the previous commits. What I can say is that EAS behaviours looked good in the end (even idle paths), but I can't unfortunately tell if some of these are still fundamental.
If cpuidle works well, it's ok to remove them. Just most of preceding commits are related with IPI, a bit concern on the following IPI commits picking up. If no, removing is ok.
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
Above commits are related with performance&power when system has more clusters. remove them may cuase perf/power issue in some cases.
Ok, I guess we might want to spend some more time fixing these conflicts then.
And finally apply the attached patches to make the branch compile.
They're ok.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Hi Juri,
What's cause conflict with about commits, HMP or some android sched change? Looks few of commit can be clean up, like deadline related.
So, we don't have HMP here as it has been removed from the integration branch. I'm not sure if we have Android sched specific changes in the branch, though. Are you aware of any in particular?
Didn't try to figure out that since HMP is in lsk-android.
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
Thanks for your comments.