MSM PMU Support in Commit ee3c454b
Hi Russell,
Commit ee3c454b `arm: msm: add oprofile pmu support' in your devel branch adds an IRQ to the static list in kernel/pmu.c. Patch 6064/1 in the patch system replaces this old functionality with runtime registration using a platform device, so this commit prevents that patch applying. The OProfile patches in the system also depend on the runtime registration patch, so they will become blocked too.
I can update the patch in the patch system so it applies cleanly, but the mach-msm bsp will need updating to register the IRQ using the new mechanism. Daniel: would you like me to submit a patch to do this, or would you rather do it [since I'm unfamiliar with the mach]?
Cheers,
Will
Quoted 8 lines · Will Deacon
Hi Russell,
Commit
ee3c454b`arm: msm: add oprofile pmu support' in your devel branch adds an IRQ to the static list inkernel/pmu.c. Patch 6064/1 in the patch system replaces this old functionality with runtime registration using a platform device, so this commit prevents that patch applying. The OProfile patches in the system also depend on the runtime registration patch, so they will become blocked too.
Oh, sorry about that. I didn't realize a change like that was pending. When are you planning to merge these changes?
Quoted 4 lines
I can update the patch in the patch system so it applies cleanly, but the mach-msm bsp will need updating to register the IRQ using the new mechanism. Daniel: would you like me to submit a patch to do this, or would you rather do it [since I'm unfamiliar with the mach]?
Either, but your more motivated as it's blocking your progress ..
Daniel
Quoted 10 lines · Daniel Walker
Quoted 8 lines · Will Deacon
Hi Russell,
Commit
ee3c454b`arm: msm: add oprofile pmu support' in your devel branch adds an IRQ to the static list inkernel/pmu.c. Patch 6064/1 in the patch system replaces this old functionality with runtime registration using a platform device, so this commit prevents that patch applying. The OProfile patches in the system also depend on the runtime registration patch, so they will become blocked too.
Quoted 2 lines
Oh, sorry about that. I didn't realize a change like that was pending. When are you planning to merge these changes?
Very very soon; the old way oprofile stuff is being supported will be going away.
Hi Daniel,
Thanks for the quick reply.
Quoted 2 lines
Oh, sorry about that. I didn't realize a change like that was pending. When are you planning to merge these changes?
I've put them in the patch system recently and Russell has been merging them since then.
Quoted 6 lines
Quoted 4 lines
I can update the patch in the patch system so it applies cleanly, but the mach-msm bsp will need updating to register the IRQ using the new mechanism. Daniel: would you like me to submit a patch to do this, or would you rather do it [since I'm unfamiliar with the mach]?
Either, but your more motivated as it's blocking your progress ..
I just posted a patch to the list. I've also superseded the outstanding PMU registration patch on the patch system with 6113/1 so that it applies cleanly to Russell's devel branch.
Will
Quoted 3 lines · Will Deacon
I just posted a patch to the list. I've also superseded the outstanding PMU registration patch on the patch system with 6113/1 so that it applies cleanly to Russell's devel branch.
This just makes the situation worse.
Quoted 4 lines · Will Deacon
I can update the patch in the patch system so it applies cleanly, but the mach-msm bsp will need updating to register the IRQ using the new mechanism. Daniel: would you like me to submit a patch to do this, or would you rather do it [since I'm unfamiliar with the mach]?
This is going to be horrible... I maintain a completely separate branch for pulling git trees into from the (multiple) branches which have the patches in.
Fixing this will tie all the branches together, which I do not want to do at the moment.
My intention is as follows:
1. Freeze the multiple branches with patches next week.
2. Apply your patches on top of the merged-set of those branches.
3. Apply the other pending patches which are dependent on these branches.
Now, at that point, the devel-stable branch won't merge cleanly back into devel because of this MSM problem, and the problem is how do we solve that.
It's not trivial, because you can't just add the platform device - it's dependent on your patch in my tree adding the enum.
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Quoted 5 lines · Russell King - ARM Linux
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Would it matter if you just did a revert on the MSM pmu patch ?
Daniel
Quoted 8 lines · Daniel Walker
Quoted 5 lines · Russell King - ARM Linux
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Would it matter if you just did a revert on the MSM pmu patch ?
No - and it might be better if you did it. I could do it on my devel-stable branch but then that'll cause you problems if you apply a patch from Will for this (but I think you'll have problems with that whichever way.)
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Daniel Walker
Quoted 5 lines · Russell King - ARM Linux
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Quoted 6 lines
Quoted 1 line
Would it matter if you just did a revert on the MSM pmu patch ?
No - and it might be better if you did it. I could do it on my devel-stable branch but then that'll cause you problems if you apply a patch from Will for this (but I think you'll have problems with that whichever way.)
I'll add a revert on my for-russell branch, then you can pull that. Is that what your thinking ?
Daniel
Quoted 11 lines · Daniel Walker
Quoted 10 lines · Russell King - ARM Linux
Quoted 8 lines · Daniel Walker
Quoted 5 lines · Russell King - ARM Linux
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Would it matter if you just did a revert on the MSM pmu patch ?
Quoted 7 lines
Quoted 4 lines
No - and it might be better if you did it. I could do it on my devel-stable branch but then that'll cause you problems if you apply a patch from Will for this (but I think you'll have problems with that whichever way.)
I'll add a revert on my for-russell branch, then you can pull that. Is that what your thinking ?
Yup.
Quoted 17 lines · Russell King - ARM Linux
Quoted 16 lines · Daniel Walker
Quoted 14 lines · Russell King - ARM Linux
Quoted 8 lines · Daniel Walker
Quoted 5 lines · Russell King - ARM Linux
Maybe I'll just keep the devel-stable branch entirely separate until the devel stuff has been merged, and then MSM can be sorted at some point later. This unfortunately means that devel-stable drops out of linux-next. It also means that linux-next is at risk of missing the merge window... again.
Would it matter if you just did a revert on the MSM pmu patch ?
No - and it might be better if you did it. I could do it on my devel-stable branch but then that'll cause you problems if you apply a patch from Will for this (but I think you'll have problems with that whichever way.)
Quoted 4 lines
Quoted 2 lines
I'll add a revert on my for-russell branch, then you can pull that. Is that what your thinking ?
Yup.
Ok, I updated my for-russell branch with a revert , let me know if that's satisfactory ..
Daniel
Hi Russell,
Quoted 12 lines · Russell King - ARM Linux
My intention is as follows:
1. Freeze the multiple branches with patches next week.
2. Apply your patches on top of the merged-set of those branches.
3. Apply the other pending patches which are dependent on these branches.Now, at that point, the devel-stable branch won't merge cleanly back into devel because of this MSM problem, and the problem is how do we solve that.
Thanks for explaining this, I was getting a bit confused by the various branches and just trying to avoid any conflicts. Now that the MSM patch has been reverted [thanks Daniel] the original PMU registration patch should apply. I've updated the patch system accordingly [discarding 6113/1 and moving 6064/1 from superseded to incoming].
Once this lot is in, we can think about MSM support then.
Thanks,
Will