|To:||"Maciej W. Rozycki" <email@example.com>|
|Subject:||Re: [PATCH 3/5] Deforest the function pointer jungle in the time code.|
|From:||"Franck Bui-Huu" <firstname.lastname@example.org>|
|Date:||Fri, 15 Jun 2007 10:59:00 +0200|
|Cc:||"Thomas Bogendoerfer" <email@example.com>, firstname.lastname@example.org, "Ralf Baechle" <email@example.com>|
|Dkim-signature:||a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s7yKOoeJWs0RITYdtPXzJvDq+7NY73mscL8TwrVBxjsb8BmMq/JObHjz8k2zKyTmb0uWE5t9lYIbi4GvRNsJvy7RTSuogu/Y7CEHZ8hWtU/zPXLESG/gWDGF/jPEQrNDsNie6e3Gz+l/svDpswZ/LrdalQoQB8GXRoH+471O1wc=|
|Domainkey-signature:||a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pWpO86ICyjYlpQJ8KdRK5FlrQ4TLYVCzjWI4jneePJnG6HCEKK5+7xE498PUtPLJMFQoIILoXOp8Y4tP51WJWGq1LRkNp4woPmwFjckdsLx7pFvcHBMpnxvwOHrCITzrV76aLDhx8dHFh4JIIEQp19bSril5jBBGjAcR7mbmIqs=|
|References:||<firstname.lastname@example.org> <email@example.com> <20070614111748.GA8223@alpha.franken.de> <firstname.lastname@example.org> <Pine.LNX.4.64N.email@example.com> <firstname.lastname@example.org> <Pine.LNX.4.64N.email@example.com>|
Hi, Maciej W. Rozycki wrote:
Well, many platforms have some sort of external timer interrupt sources (like an 8254 or an DS1287 or even a more sophisticated timer; sometimes integrated in the south bridge and collecting dust there), but people tend to follow the path of least resistance and use the CP0 timer, even though it is is a valuable resource that may be used for some other purposes. I
Which other purposes ? CP0 hpt gives generally the highest precision for a given platform, and it seems to be your case too. I don't see which other better purpose it can deserve other than hrtimer, tick interrupt...
think the issue has been raised here many times already. The CP0 timer has its problems too as it is one-shot only and needs complicated recovery if an interrupt is missed -- see c0_timer_ack().
Well I would say that because it's one-shot, it's a good timer to choose. I don't see how you can have hrtimer support if you choose a periodic timer... And missed interrupts doens't seem a big deal, and the new kernel time subsystem handle them for us already.
Please note that this generic calibration code may be used for calibrating the CP0 timer too -- all that you need is defining
Actually the current patchset breaks it since it changes the calibration code to be used only for the cp0 hpt calibration. I'll change that.
mips_timer_state appropriately, i.e. to flip at the HZ rate (it may be based on one of the south bridge choices mentioned above or some free-running counter for example), but people seem to prefer to write their own code for some reason. ;-)
Do you have any examples in mind which rewrite their own calibration code ? I'm too lazy to search into all board code.
1. No HPT at all. 2. HPT in the chipset. 3. HPT in CP0. depending on the configuration as determined at the run time, with no predefined frequency in the cases #2 and #3.Good to know.And FYI for DEC CP0 is meant to be the last resort (current code does not
Again IMHO it should be the first choice if possible. -- Franck
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 12/12] drivers: PMC MSP71xx security engine driver, Evgeniy Polyakov|
|Next by Date:||Re: [PATCH 3/5] Deforest the function pointer jungle in the time code., Maciej W. Rozycki|
|Previous by Thread:||Re: [PATCH 3/5] Deforest the function pointer jungle in the time code., Maciej W. Rozycki|
|Next by Thread:||Re: [PATCH 3/5] Deforest the function pointer jungle in the time code., Maciej W. Rozycki|
|Indexes:||[Date] [Thread] [Top] [All Lists]|