> -----Original Message----- > owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley > Sent: Wednesday, October 28, 2009 1:37 AM > [..] > a comment on cpu_relax() and udelay(). > > On Mon, 26 Oct 2009, Menon, Nishanth wrote: > > > > -----Original Message----- > > > From: G, Manjunath Kondaiah > > > > > > As per your comments for other patches when ever there is udelay usage, > > > cpu_relax is the better option. I see there are lot of udelay(...) > calls > > > used in this patch. Why can't you use cpu_relax() or schedule(). > > > Any specific reason? > > > > > Donʼt really want to do cpu_relax in irq_locked context.. > > There are no restrictions on the calling context for cpu_relax(). > [ schedule(), of course, does have restrictions. ] Thanks.. > > I don't understand the use of the udelay(10). Could you please explain > this further? Is it the case that if the register bit doesn't change > within 50 reads, that it is then not likely to change for 10 microseconds? The delay of 10 used is in vcbypass command -> the loop actually waits for the i2c command to get thru.. depending on the speed of the bus configured and cpu speed, 50 iterations might not be enough, but yes, a udelay(1) loop in addition to cpu_relax might be better.. > > If that isn't how the device works, then using udelay(10) will just waste > power busy-looping in the CPU. I would rather see this code using > udelay(1) between each register read if you want to ensure that you read > the register for at least 50 microseconds. This would also simplify your > timeout loops considerably, which seem unnecessarily complicated. Ack. Regards, Nishanth Menon -- 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
