From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 00457DE055 for ; Wed, 11 Mar 2009 11:25:06 +1100 (EST) Subject: Re: [PATCH v5] introduce macro spin_event_timeout() From: Benjamin Herrenschmidt To: Timur Tabi In-Reply-To: References: <1236723118-3577-1-git-send-email-timur@freescale.com> <49B6EAA4.9000803@freescale.com> <20090310223753.GB26415@zod.rchland.ibm.com> <1236729551.7086.26.camel@pasglop> Content-Type: text/plain Date: Wed, 11 Mar 2009 11:24:57 +1100 Message-Id: <1236731097.7086.32.camel@pasglop> Mime-Version: 1.0 Cc: Scott Wood , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote: > > Alan did have one valid point though. Determining how long to loop > for is architecture-specific. Using jiffies is bad, because even one > jiffy is too long. Adding a udelay() inside the loop means that it > only checks he condition every microsecond. So the real solution is > to use keep looping until a certain amount of time has passed. This > means using an architecture-specific timebase register. > Now we can create a generic version of the function that uses jiffies, > and then arch-specific versions where possible. But Alan still needs > to be convinced. I already posted a length rebuttal to his email, but > I haven't gotten a reply yet. > There are several aspects here: - The amount of time to wait should be specified by the caller since it's generally going to come from HW specs - The amount of time between the polls ... that could also be an argument to the macro, not sure there - The precision of the actual wait calls... I vote for microseconds for everything and udelay. The arch will do its best. Cheers, Ben.