Received: by 10.192.165.148 with SMTP id m20csp3357240imm; Mon, 7 May 2018 10:51:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoWGD/KCt2Qn6N2oohjSKeSG5RoPLeuB1KNDn0nNn73YwRl24/SpSWvkoMifuo8bmRwdXwK X-Received: by 2002:a24:2f89:: with SMTP id j131-v6mr2288172itj.96.1525715472228; Mon, 07 May 2018 10:51:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525715472; cv=none; d=google.com; s=arc-20160816; b=zBk1UyzfrBoH1aSrbc8I6LvkL3HIG/vWRSKkOxUMWtZJJ5twiy5pLnUTdJ7OFs4VYI xGzRD5nxuQVwIJkMnZw4SrHZ9KSGO+qTsK1HczHiSILST6mXJhe7WMem04zwyo62lv86 7Se/9jFFzlMz5z+uX2Ytg9dxQvKwHd4S7FKykCN/rsPHpYIxiXdijs2IkTldCCP+m3oC wkeHFV3bH/dGc5ZaZg0bLAcIxjsfGvD+wbbZuUjWrr/Kgx3gEw0VypjG2Qvq4AXt1CTy vwZlSKYbomLa8PS68EEAVC/rayVbHHU/IJLtVu7Xhz43fyNI3tqdCQnao1IZovdu0WCE jl/w== 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=D1qzNOKeFvR6hGBcKpY3aZ2X1H63cHPdxcGHGs5mHYQ=; b=JbceDtuIZHHS3qjCXrpP2mFL7j7KXU+qbqjnFxNEGaFXb/VsXN8jLAWMRQFgXc21/6 KPV4+5o7MlIAe/fkPTMjhsi7tUrQL94ZTPUGbbo8Pb4k2KpbevQ0olHvQwDI5/CuyKpg CU2j/fdoHqtGdqwdwpk+BGyZbCfGAZ3GcrArBlWWy6C9jp3Bx/296KeAYDvnxj/sOoKO iG+jFJKa88QPbNtcQUtb/S9PFIDO2Y4PmBhh0MR8gdLUpgj5ORoX258Z9SPgSia2qmiO Qken31ERtoeSVVn3lAZxDmYhisCQocuix+qiIalXnTsWs7Rpt2ocLlKj2B9gI/HbU0+R vzDg== 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 k68-v6si7718477ite.45.2018.05.07.10.50.58; Mon, 07 May 2018 10:51:12 -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 S1752579AbeEGRuh (ORCPT + 99 others); Mon, 7 May 2018 13:50:37 -0400 Received: from muru.com ([72.249.23.125]:40930 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751976AbeEGRug (ORCPT ); Mon, 7 May 2018 13:50:36 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 0B65A80C7; Mon, 7 May 2018 17:52:33 +0000 (UTC) Date: Mon, 7 May 2018 10:50:32 -0700 From: Tony Lindgren To: Johan Hovold Cc: Sebastian Reichel , "H. Nikolaus Schaller" , Andreas Kemnade , 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: <20180507175032.GR98604@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> <20180507100135.GS2285@localhost> <20180507154515.GP98604@atomide.com> <20180507163439.GV2285@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180507163439.GV2285@localhost> 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 * Johan Hovold [180507 16:36]: > On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Johan Hovold [180507 03:03]: > > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote: > > > > > > > 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). > > > > > > I'm not sure we want generic runtime-pm support for the controllers in > > > the sense that the slave device state is always reflected by the serial > > > controller. Similar as for i2c and spi, we really only want to keep the > > > controller active when we are doing I/O, but we may want to keep a > > > client active for longer. > > > > Yeah i2c seems to do the right thing where the bus takes care > > of runtime PM. > > Yeah, but since serial is async in contrast to i2c/spi, we may not be > able to push this entirely into core. The serdev drivers may need to > indicate when they expect or need to do I/O by opening and closing the > port. And this is how I implemented these first couple of gnss drivers. OK > Also note that most serial driver do not do runtime pm while the port is > open (as OMAP does), and doing so also has the drawbacks of lost > characters etc. as Sebastian mentioned. Yes serdev seems really nice for the oob wake gpios :) > > > Take the u-blox driver in this series for example. As I'm using runtime > > > PM to manage device power, user-space can chose to prevent the receiver > > > from runtime suspending in order to avoid lengthy (re-)acquisition times > > > in setups without a backup battery (by means of the power/control > > > attribute). > > > > Sorry I don't seem to have that one, care to paste the subject > > line of that patch? > > "[PATCH 5/7] gnss: add driver for u-blox receivers" > > https://lkml.kernel.org/r/20180424163458.11947-6-johan@kernel.org Thanks will take a look. > > > Note that serdev not enabling runtime pm for controllers is roughly > > > equivalent to setting the .ignore_children flag, which is what we do for > > > i2c and spi controller, and possibly what we want here too. > > > > We currently don't idle serdev at all even if not in use. What > > I noticed is if I have these in my .config: > > > > CONFIG_SERIAL_DEV_BUS=y > > CONFIG_SERIAL_DEV_CTRL_TTYPORT=y > > > > And no hci_serdev.ko driver loaded, then the 8250 port still stays > > active and there are no sysfs entries to idle it. > > Sounds like the 8250_omap driver is doing something funky. Why would > there not be any sysfs attributes to control runtime pm? I don't know, they are there for the ports that don't have any serdev device. But if there is a serdev child node, the sysfs disappear for the 8250 port like it's /dev/ttyS* entry. That is even with no hci_serdev.ko loaded :) > > Are you seeing this with your series? > > I'm using omap-serial (on BBB) and like 8250_omap, the driver disables > runtime pm at probe by setting a negative autosuspend timeout. Hmm I though we now have both 8250_omap and serial-omap behave the same way for PM. > Changing this through sysfs causes the serial controller to runtime > suspend, but something is not right in my setup as it doesn't wake up on > incoming data. Do you have also a /dev/ttyO* entry created for the serdev port? > I'd say the omap drivers are broken; the controller should definitely > idle when the port is closed (whether using serdev or not) without > having to fiddle with sysfs. This is happening for the non-serdev ports for sure. FYI, there is one patch needed for omap4 to idle unused ports that I posted few days ago: [PATCHv3] serial: 8250: omap: Fix idling of clocks for unused uarts But the serdev port is never idled, even if unused. Can you check your serdev port clkctrl reg with rwmem or similar tool when it's idle? You can do it with: rwmem -s32 0x44e004b4 # uart 1 on l4_wkup rwmem -s32 0x44e0006c+0x10 # uart 2 - 5 on l4_per rwmem -s32 0x44e00038 # uart 6 on l4_per And here's what I have on my bbb with 8250_omap: 0x44e004b4 = 0x00000002 0x44e0006c = 0x00030000 0x44e00070 = 0x00030000 0x44e00074 = 0x00030000 0x44e00078 = 0x00030000 0x44e00038 = 0x00030000 So all disabled except for the console UART. Regards, Tony