From owner-freebsd-arm@freebsd.org Tue Sep 10 15:54:15 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 124A7DA7DA for ; Tue, 10 Sep 2019 15:54:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46SV2Z4dSTz4bSB for ; Tue, 10 Sep 2019 15:54:14 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1568130853; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=ENGunz+CmJlMoM7mAvaw/UPnSaKtVPNfkTMuHI5TXgHZVGsCBJFFly2dB5ydQoNtuALbwgtr8QSyu 7FhUjWf1H8WD8Y59rAl+vlejoU+fAkY+Oytd04UY9Yp7LGwPRSvmwKfU2H3YJombZcSZfrKw7b9011 4Gr1/plJQT6c+VZDmp/rqiDPivpPVIirysYeOntxw6zk8YGNsBJ53b7Bu2Xc2F68PHQaPbRGgVMIDE Dvs3fbWVrqQP/k3QkPWJ7EeG05EFA99z3GNiL8oUNpSAcIWGeNtaAyIezUVMOeCVPhya7Rx9ZHgja3 QVWf9Y4+2EnfLuppJTQPS3Qg8iCtPWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=zxzcmyumSelo87QcKnq6gMvnJMh03eGKM0gtEz4UzaI=; b=V556ZG+1gNLzuXh8SWCh/vNw2Bii7RbI5VJXoSAy2fNgEuLp5lB6SuXoXWh/0LSGFyZeRglVX8KaR jQIXhsxj+KpjM6f7qtmfce7Ie/xEQhdrGl5E7bWM2b0jZzJKshqbypQi4QNs58Q+13Quvb264aZsY9 QPJt0vPmwnf4QK36vkG9Xm9P0tpwafDmozBxDOS/Bo3JFPI+qvlDbXdQUaHT7DL64xh6me7ocXErrA rq6glct5QJtgbI/UxNC3cAivyD0bzTKejkyYAww24K/Fni+JzLmhBDHlL+xwxt+J60wZpDfVckuVfG gISFM4t87lAZ4peNd36F1p1aZPr7MEA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=zxzcmyumSelo87QcKnq6gMvnJMh03eGKM0gtEz4UzaI=; b=wxKI7T5CR/IGSMlX0gHGe9SZms6eR8J0PnnMlGp+Hshkpg3wCYLwgYrORZDxowcC1jECmUN/eq/m/ UXUcQLnA+IFiJnPmhKl0HTkEcvLRzvGdqrsbwgaQGPCfQKJKk9GWY+GbodXUZ/2vMvS3Y53KQKZx42 EhFFhLmdEjU4XtyM9jZYJzOJ8nyweWBKaIPKy7NbvRPnCN8+lm2FUgRyVd9MNcf4+9okPj/2JFqzhF R/Ke+SIpJ+VwGHZkOSfb7BVNYJ68ojJBQCtqiZh2ug2Rf+ESTx2A5g2DZxgPudjdjCwYKJ90bNEPmV h6p4fKd+laUc8Zo3b0iu2Lc/im/YHJg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3a64a9c2-d3e3-11e9-b67d-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 3a64a9c2-d3e3-11e9-b67d-cdd75d6ce7a8; Tue, 10 Sep 2019 15:54:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x8AFs9kX067087; Tue, 10 Sep 2019 09:54:09 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <3af74fe770557e2fee098a6353e4685bab504dc2.camel@freebsd.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. From: Ian Lepore To: Konstantin Belousov Cc: "O'Connor, Daniel" , "freebsd-arm@FreeBSD.org" Date: Tue, 10 Sep 2019 09:54:09 -0600 In-Reply-To: <20190910144059.GA2559@kib.kiev.ua> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> <9D2ACA87-C2DB-40D9-9638-B0E215A4EEC0@dons.net.au> <0A7796DA-508B-4FE6-B5C0-391EC5F46C86@dons.net.au> <20190908134205.GO2559@kib.kiev.ua> <25BF53F1-23CF-4619-AB13-110566D6DC82@dons.net.au> <20190909164501.GT2559@kib.kiev.ua> <20190910144059.GA2559@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46SV2Z4dSTz4bSB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 15:54:15 -0000 On Tue, 2019-09-10 at 17:40 +0300, Konstantin Belousov wrote: > On Mon, Sep 09, 2019 at 04:19:48PM -0600, Ian Lepore wrote: > > On Mon, 2019-09-09 at 19:45 +0300, Konstantin Belousov wrote: > > > [...] > > > Still the question is why your system have the negative impact from > > > reducing the number of timehands. Interrupt should never interrupt > > > tc_windup() because it is protected by spinlock. Silly question, are > > > spinlocks functional on this machine ? > > > > > > > > > > > Yep, spinlocks work fine. > > > > The problem sequence that happens, as I remember it, is that the system > > is sleeping in cpu_idle() which has stopped the single core with the > > WFI (wait-for-interrupt) instruction. The wakeup from WFI is an > > eventtimer event that was scheduled to handle state->nexthard to keep > > the timecounter updated. As part of handling that event, the system > > calls the timecounter's tc_poll_pps function (which is dmtpps_poll() in > > arm/ti/am335x/am335x_dmtpps.c). That captures the pps event time using > > the current timehands, then schedules a taskqueue task to finish > > processing the captured data. By the time the taskqueue task runs, > > tc_windup() has been called more times than there are timehands, so > > pps_event() rejects the data because th->th_generation captured in > > dmtpps_poll() does not match th_generation in that set of timehands > > anymore. > > Is it really needed to schedule task for pps_event() ? > > We don't for tc_windup(), and pps_event() is quite similar. > And for pps_event(), we might use same opportunistic locking as > for tc_windup(). > I think it is not necessary anymore, and I should fix that. It was necessary when the code was originally written. The call to pps_event() has to be protected by a mutex because the same data is accessed via ioctl(). The timecounter polling routine is called in primary interrupt context where sleeping is not allowed, so the old way to structure a hardware- capture driver was to do the pps_capture() (which doesn't need mutex protection) in the polling routine called from a filter handler and defer the pps_event() processing to context where sleeping is allowed. In May 2015 I committed some changes to the pps api stuff that allows using a spin mutex, so I could change the kind of mutex used by the driver and eliminate the taskqueue stuff completely. -- Ian