On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote: > On Wed, 13 Mar 2013, Santosh Shilimkar wrote: >> On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote: >>> With recent arm broadcast time clean-up from Mark Rutland, the dummy >>> broadcast device is always registered with timer subsystem. And since >>> the rating of the dummy clock event is very high, it is preferred >>> over a real broad-cast clock event. >>> >>> This is a change in behavior from past and not an intended >>> one. So reduce the rating of the dummy clockevent so that >>> real broadcast device is selected when available. >>> >>> Without this all the C states with C3STOP won't work since >>> the broad cast notifier will take an abort. >>> >>> Cc: Mark Rutland <mark.rutland@xxxxxxx> >>> Cc: Russell King <linux@xxxxxxxxxxxxxxxx> >>> >>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx> >>> --- >>> Its a regression so hopefully can get into the 3.9-rcx. Noticed >>> this one on A15 platform. A9 platform the issue may not be seen >>> since the local timer check avoids dummy timer registration. >>> >> Some one pointed me to a fix made by Mark which was discussed >> under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject. >> That patch seems to be more of work around since the root of the >> problem is incorrect dummy timer rating. Either way, both patches >> fix the issue. > > Well, using a dummy timer as the broadcast event device is a bug, no > matter what the rating is. The fix is in Linus tree already. > Agree. > Though making the rating of the dummy lower is definitely a good > thing, so a real hardware device which is detected later can replace > the dummy device. So yes, the rating should be low for the dummy > timer. > Exactly. As Mark pointed out, you have already applied Mark's patch. I was just wondering whether you can take the $subject patch as well with ack from Russell, Mark. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
