From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41773C433F5 for ; Mon, 29 Nov 2021 16:44:01 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 1BD761930; Mon, 29 Nov 2021 17:43:09 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 1BD761930 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1638204239; bh=FDmv1JyksfB2gIoJRklgg6/odSHZUmJG2H8xTMiX+5o=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=h3rWBkMQG1vYGahQYr98uihImpPynnHGAQaKUDzd0/mdc/4kRxUAM0EKjhRfVu/8Y ZvkqsQ5U/Y23ZuV6vxm+Di8kX87DN1FxLGOtRVX/SLOWc23lxiXiVNwgDmt09GnSVN A0xiLVikhbGPgLUbeiCuI5LI4yJYzezYPa3GwqdE= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id ACAB0F80217; Mon, 29 Nov 2021 17:43:08 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8D89EF80240; Mon, 29 Nov 2021 17:43:07 +0100 (CET) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8D653F8020D for ; Mon, 29 Nov 2021 17:43:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8D653F8020D Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="LYXA0zj1"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="h6W4UHNV" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D38B61FD38; Mon, 29 Nov 2021 16:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1638204179; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QUKCOvl4CJzvTmXhb5oVQ1MaaCyer2L/UBKhuNmXlNw=; b=LYXA0zj1FqXGmG8eK0DdZn6tOPHh4hOfEXHwnUGG+R0d4SAfYGSwcQUhe5PuMJmr8eM2fd LswxuQchBqukhpcJTxW8krelfowk3aWV78EwHiBy6W04UzQQVbCvNJzt563AB4cbEYDihJ EEyOCGjFQDGLhvv8rnDTCpR1SHfPQ5A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1638204179; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QUKCOvl4CJzvTmXhb5oVQ1MaaCyer2L/UBKhuNmXlNw=; b=h6W4UHNVXBKHondIK8rDGaR28qJJ5gL9RHhk1KSMGskYnIxilFWeOJ/bGpHDDX1lls5HYT XPXb9xrUUPBpxzBg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id B2109A3B84; Mon, 29 Nov 2021 16:42:59 +0000 (UTC) Date: Mon, 29 Nov 2021 17:42:59 +0100 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart Subject: Re: ALSA: hda: Make proper use of timecounter In-Reply-To: <4c1b9ecd-cefe-f890-f309-39d602201d58@linux.intel.com> References: <871r35kwji.ffs@tglx> <4c1b9ecd-cefe-f890-f309-39d602201d58@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Cezary Rojewski , alsa-devel@alsa-project.org, Jie Yang , Takashi Iwai , LKML , Liam Girdwood , Thomas Gleixner X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Mon, 29 Nov 2021 17:06:40 +0100, Pierre-Louis Bossart wrote: > > > > On 11/24/21 4:40 PM, Thomas Gleixner wrote: > > HDA uses a timecounter to read a hardware clock running at 24 MHz. The > > conversion factor is set with a mult value of 125 and a shift value of 0, > > which is not converting the hardware clock to nanoseconds, it is converting > > to 1/3 nanoseconds because the conversion factor from 24Mhz to nanoseconds > > is 125/3. The usage sites divide the "nanoseconds" value returned by > > timecounter_read() by 3 to get a real nanoseconds value. > > > > There is a lengthy comment in azx_timecounter_init() explaining this > > choice. That comment makes blatantly wrong assumptions about how > > timecounters work and what can overflow. > > > > The comment says: > > > > * Applying the 1/3 factor as part of the multiplication > > * requires at least 20 bits for a decent precision, however > > * overflows occur after about 4 hours or less, not a option. > > > > timecounters operate on time deltas between two readouts of a clock and use > > the mult/shift pair to calculate a precise nanoseconds value: > > > > delta_nsec = (delta_clock * mult) >> shift; > > > > The fractional part is also taken into account and preserved to prevent > > accumulated rounding errors. For details see cyclecounter_cyc2ns(). > > > > The mult/shift pair has to be chosen so that the multiplication of the > > maximum expected delta value does not result in a 64bit overflow. As the > > counter wraps around on 32bit, the maximum observable delta between two > > reads is (1 << 32) - 1 which is about 178.9 seconds. > > > > That in turn means the maximum multiplication factor which fits into an u32 > > will not cause a 64bit overflow ever because it's guaranteed that: > > > > ((1 << 32) - 1) ^ 2 < (1 << 64) > > > > The resulting correct multiplication factor is 2796202667 and the shift > > value is 26, i.e. 26 bit precision. The overflow of the multiplication > > would happen exactly at a clock readout delta of 6597069765 which is way > > after the wrap around of the hardware clock at around 274.8 seconds which > > is off from the claimed 4 hours by more than an order of magnitude. > > > > If the counter ever wraps around the last read value then the calculation > > is off by the number of wrap arounds times 178.9 seconds because the > > overflow cannot be observed. > > > > Use clocks_calc_mult_shift(), which calculates the most accurate mult/shift > > pair based on the given clock frequency, and remove the bogus comment along > > with the divisions at the readout sites. > > > > Fixes: 5d890f591d15 ("ALSA: hda: support for wallclock timestamps") > > Signed-off-by: Thomas Gleixner > > I don't recall the reason of why I added separate steps for > multiplication by 125 and division by 3 back in 2012, but obviously they > weren't aligned with my own comment "Max buffer time is limited to 178 > seconds to make sure wall clock counter does not overflow". > > Thanks for the patch, much appreciated. > > Reviewed-by: Pierre-Louis Bossart Now queued to for-next branch. Thanks. Takashi