Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751534AbdILPyo (ORCPT ); Tue, 12 Sep 2017 11:54:44 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:44912 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbdILPym (ORCPT ); Tue, 12 Sep 2017 11:54:42 -0400 X-Google-Smtp-Source: AOwi7QCD+oHaXmGVCLX6EkCihJaOgWQ5SgWXHCgkLC6x+8MTjnKX+6nDJR2xIqRfuvludz026f6xrzXWpobsU7iGEE8= MIME-Version: 1.0 In-Reply-To: References: <1504900414-1514-1-git-send-email-tharvey@gateworks.com> From: Tim Harvey Date: Tue, 12 Sep 2017 08:54:40 -0700 Message-ID: Subject: Re: [PATCH] pps-gpio: use IRQ edge config when not capturing both edges To: Rodolfo Giometti Cc: "discussions@linuxpps.org" , "linux-kernel@vger.kernel.org" , Koen Vandeputte Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1655 Lines: 45 On Sun, Sep 10, 2017 at 3:43 AM, Rodolfo Giometti wrote: > On 08/09/2017 21:53, Tim Harvey wrote: >> >> PPS signals with very short pulse-widths can be missed if their state >> changes by the time the interrupt handler reads the GPIO pin state. >> >> To avoid this in the case where we are only looking for one edge we can >> use the edge configuration for the pin state but fall back to reading the >> pin if both edges are being watched. > > > I disagree. The "rising_edge" status should be get from the hardware and not > derived by an empirical computation. Or, at least, it should be specifically > activated by setting something like this: > > pps { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_pps>; > > gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; > Yes-I-want-get-signal-status-in-an-epirical-way; > > compatible = "pps-gpio"; > status = "okay"; > }; > > This setting should also print a warning in order to be clear for the user > that he/she should know what he/she is doing. > > Then the code should check also the compatibility with property > "assert-falling-edge"... > Hi Rodolfo, Do you agree with using the irq edge in general if/when it is available to resolve the case where small pulse-widths can be caught? I assumed because pps-gpio is the one configuring the irq based on info->capture_clear and info->assert_falling_edge that that it made sense to use that logic again when handling the interrupt but there is likely a call I can make to determine the irq (edge) type based on the irq. Tim