From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 05:36:19 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04511106566C for ; Thu, 22 Jul 2010 05:36:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 818398FC19 for ; Thu, 22 Jul 2010 05:36:17 +0000 (UTC) Received: by fxm13 with SMTP id 13so4454215fxm.13 for ; Wed, 21 Jul 2010 22:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=xu1Zb24p7qw0t7NnHwnLJEYjiCmOorXNmornBqJ7ElE=; b=QLo934TSJbXS+3lITq6BImOtpq6rrY2oUCPQLxSQTpWGU292l04x5GRrdrZJWjNOcf 4DXpaVBna+k/LEAEwzMQy/DZdHPiXViaNHIRPjQXD7etUaMSA8ia8TcvojxeYmBLahyf KNzOMy+PvcyL3Mj1PNE+Qzk9DKzmgOBb7peOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QwPs5SPCnzx+gASvqa0RmU2Zx7+odsKSj6BuFPYarqZPhnZIoHwY0RSy7yOcaSJPFv lJ39zipEulP9HRXFSEf0DifP9952RZ1GTAe2i6ia5e36ZI+qHzxeIOdwPngMpQy7/a/b eSM1b+eIfciwENIlfFto8pHoiq76fRTgCDTrM= Received: by 10.223.126.84 with SMTP id b20mr1226850fas.98.1279776976580; Wed, 21 Jul 2010 22:36:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r2sm3177313faq.4.2010.07.21.22.36.15 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 22:36:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C47D8CD.7020209@FreeBSD.org> Date: Thu, 22 Jul 2010 08:36:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Neel Natu References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 05:36:19 -0000 Hi. Neel Natu wrote: > Your patch works fine on a Sibyte. I verified that wall clock time is > progressing as expected. Is there any other test that you recommend? > > I have a few comments about the patch: > > 1. set_cputicker() in clock_attach() should be moved back up to > mips_timer_init_params(). Otherwise the platform-specific CPU tickers > used by Sibyte, Octeon and RMI will be overwritten by the mips32 ticker. Fixed. > 2. The local variable 'cycles_per_tick' in clock_intr() can now be a uint32_t. Fixed. > 3. Is there a race between setting 'cycles_per_tick' in clock_start() and > clock_intr()? Would it be better to write the compare register first > and then set 'cycles_per_tick' to a non-zero value? And how does it help? > If I understand the code correctly we are liable to get clock interrupts > even afer the clock is stopped when the CP0 COUNT register matches > 0xffffffff. You mean we can receive interrupt from previous clock_start() after new one? Theoretically I think it is possible, but what can we do about it? > 4. We need to update the DPCPU(compare_ticks) value when we start the timer > in clock_start(). Fixed. > 5. I think the entire 'lost_ticks' processing in clock_intr() should be > conditional on (cycles_per_tick > 0). Without this we may incorrectly > update the value of DPCPU(lost_ticks). Fixed. Indeed, in one-shot mode extra callback can be confusing. > 6. Can you a couple of lines of explaining the computatation of > 'et_min_period' and 'et_max_period'? It is not completely obvious to me. Minimal period is set artificialy to reduce possibility to lost very short time interval during comparator programming. I've done it after marius@ asked to do the same for sparc64. If this comparator is more clever to handle missed time, it may not be needed. Maximal period is calculated from maximal counter value, minus one to possibly avoid some rounding overflows. Again, if this comparator is "clever" may be it need to be reduced. I don't have documentation for this hardware, so fix me if I am wrong. New patch: http://people.freebsd.org/~mav/timers_mips3.patch Thank you! -- Alexander Motin