Received: by 10.192.165.148 with SMTP id m20csp113265imm; Fri, 4 May 2018 07:30:55 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqkQ9fxUH6ckokgy6ZZQpctEWMbFcMk3nne0bY9futsgzA5X43PwDDLwPYvmSVL7VBMV409 X-Received: by 2002:a63:ac56:: with SMTP id z22-v6mr22414674pgn.411.1525444255467; Fri, 04 May 2018 07:30:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525444255; cv=none; d=google.com; s=arc-20160816; b=XGy1ur5BmyPCbGED0zkfJxAyOL1xOwxlLYplinLP/SByuXWJKfarjSlB8RqzR0wFtu MO1YaFA4YiS2urI/wx7VOIyHspBdEPh4aXF98prfxti7MeaPJs32odbOFOE28HuDBhd6 JbyhWWuMYswQz9Nd9LsPP17wuXjgKl7GJEUGlv8MWgR+67kEFe/3m6ybHj+Mk8fPc+kK 3Z9mV3XehcjGHMe667effkIbA2Lo3MR3e0Rj2q4x+vljQUPw3b1Czglr5t3JLXF3RkB1 iTWB7C9QHK1Oq3LESA+IBbdErVQV3RCmQ4cqB7NgH7jgoHOdy8OkkbOTj7lQp9kNWTZe Aa8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=OE00LsZQtSvkCWTKBGwj9QPE5sppReFSj+Kq1xkcM7E=; b=zJgAz2raD5Yc6Y1BarWqmusTxLXc1f56eHzOfn8w+fx4Nr25VgEoldzeTB3R3drz0d 0E9Q2F4IxT5BYuhlVrirDHYJ6NMb6tPhg/dUFJratx1lzNzu3O0cvNzVu3neV9lEQBaw vqrH5CpDPZyZFTZJqLzyrtzgwrNkkkjKB36huePfd2TleyKsx4NCFbDwUMs40VHnlZZQ I1jRgZZ6bo8XdAzDspyA4sA0BdddZATMkkD4KGtL+WLaXLAKR5efSZIY2B+fZKRsPq8a ZMko5QsFCuh4t0aqFlaKEAF7zoTfF2TbmE6WJmTmYtG5pEPrPOfIgmVHRALUMxSkUd7v hUqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si15654465plk.83.2018.05.04.07.30.41; Fri, 04 May 2018 07:30:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751832AbeEDOaF (ORCPT + 99 others); Fri, 4 May 2018 10:30:05 -0400 Received: from muru.com ([72.249.23.125]:40234 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751314AbeEDOaC (ORCPT ); Fri, 4 May 2018 10:30:02 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id BABC280CC; Fri, 4 May 2018 14:31:56 +0000 (UTC) Date: Fri, 4 May 2018 07:29:58 -0700 From: Tony Lindgren To: Sebastian Reichel Cc: "H. Nikolaus Schaller" , Andreas Kemnade , Johan Hovold , Mark Rutland , Arnd Bergmann , Pavel Machek , "linux-kernel@vger.kernel.org" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Greg Kroah-Hartman , Rob Herring Subject: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding Message-ID: <20180504142958.GB98604@atomide.com> References: <20180426091018.GU4615@localhost> <20180502081637.GE2285@localhost> <5242FCAD-3139-4A9C-B9FA-7BBAA0E6AE57@goldelico.com> <20180503205037.7be552c1@aktux> <44A0BC7C-67C7-4116-849F-90FF7CF2B1F0@goldelico.com> <20180504114213.3xlzqxe74n55tk5s@earth.universe> <20180504133759.xauwewrqevsbhjyr@earth.universe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180504133759.xauwewrqevsbhjyr@earth.universe> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sebastian Reichel [180504 13:40]: > Hi, > > On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote: > > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel : > > >> I think it does not need much more (if at all) than a gpio controller on > > >> the OMAP3 chip (I think the clocks are active anyways for use by the other > > >> UARTs). > > >> > > >> We had proposed years ago to reprogram the UART RX pin by pinmux-states > > >> into an interrupt gpio but that was rejected because it was not general > > >> enough and ugly in the device tree (an rx-gpios record where the rx-line > > >> is already connected to the UART-rx). > > >> > > >> Then we did experiment with tapping the UART driver and finally the > > >> serdev API was developed to solve this problem. Hence we use it now this > > >> way. > > > > > > Having any UART active on OMAP results in the SoC not entering > > > idle/off wasting energy. For normal (i.e. not connected to a peripheral) > > > TTYs you can enable runtime autosuspend and configure the RX pin as > > > wakeup interrupt. This will wakeup the TTY on incoming traffic, but you > > > will lose the first few characters (since the serial device needs some > > > time to wakeup). This is for example supported by the N900 uart3 > > > (debug uart): > > > > > > $ grep -A4 "&uart3 {" arch/arm/boot/dts/omap3-n900.dts > > > &uart3 { > > > interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>; > > > pinctrl-names = "default"; > > > pinctrl-0 = <&uart3_pins>; > > > }; > > > > > > To get it working, you also need to enable autosuspend for the tty > > > in userspace (echo 3000 /sys/class/tty/ttyS2/device/power/autosuspend_delay_ms). > > > This is not enabled by default due to the character loss characteristic > > > during wakeup. > > > > > > Having said all of this, serdev does not yet support runtime PM (at > > > all). Tony is currently looking into it. Fortunately serdev allows > > > us to enable runtime PM by default (once implemented), since we know > > > the remote side and can (hopefully) avoid losing characters (i.e. > > > with sideband wakeup gpios). > > > > thanks for explaining this! We originally had similar thoughts when > > proposing a w2sg0004 driver for the first time (years ago), but we can > > not accept loosing characters... > > > > Now, I could imagine a potential solution. The key situation why we keep > > the serdev open and listening is if the driver did try to turn the module > > off, but in fact did turn it on (because it was not in sync). > > > > It should be possible to cover this by a timer that is started > > in this case. If there is serdev data received after assuming the module > > is turned off, the driver has detected the wrong case - and can safely > > close the serdev until we want to have it powered on again. > > > > If there is no response after turing off, the module power state is already > > in sync and we can close the serdev as well - after the timeout (let's say > > 30 seconds). Then, the serdev UART can idle. We should open the serdev > > and start this timer also in the probe function to catch an initially wrong > > state. > > That sounds like a good plan. I don't know the details, but sounds like you should might be able to just the timer that comes with pm_runtime_use_autosuspend() :) Regards, Tony