On Wed, Nov 09, 2011 at 11:40:21AM +0400, Gleb O. Raiko wrote: > On 08.11.2011 21:55, Ralf Baechle wrote: > >but we may need another hazard barrier to > >replace back_to_back_c0_hazard(). > Urgently. We need some ticks to wait until counter state machine has > been updated. The amount of ticks may occasionally be the same as in > case of back_to_back_hazard for some cpus. It's completely different > for others, I sure. Original compare_change_hazard waits up to 12 > ticks for r4k. While I don't think this amount should depend on > irq_disable_hazard as old code assumes, we may still need 12 or so > ticks for old cpus. Hmm... Looking at the R4000 manual which generall has the longest pipeline hazards, mtc0 gets executed at stage 7, interrupts get sampled at stage 3 meaning there is a (7 - 3 - 1) = 3 cycles hazard. Does that one statisfy your constraints? Or are additional cycles needed for a hazard that's generated outside of the CPU's pipeline? Ralf
