Received: by 10.192.165.148 with SMTP id m20csp3283750imm; Mon, 7 May 2018 09:35:44 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr3Z7mzLpYB1Ka5DoWyKvqgYsHrxdge/HguN/b0OXThLU/oWduLESro+fpMEfhrYJAY5bQY X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr20109766ioa.265.1525710943963; Mon, 07 May 2018 09:35:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525710943; cv=none; d=google.com; s=arc-20160816; b=z3oMVH/qAP9BPEL4IVAjcDhHsoncOVAfMI0VnMphOCjuvmWe7O/hM4CtQkGCE8J7bM hMjDe7e6FEUQQ+uOtLoTaUUwvuTmAZGsQWlP8aW9HNCKgC/aja7faTAnuLVwZO+GBmbk Pc+uzezK1zr7YMiuhFgw7wAkgXSBEvYU7gxYP6pgpy56YYZmOlO3EsgwnSbyuc9LLgSp rvrJREAY0SFI8s9lywRSA/ToNIlz15SCTJni0l+9TPSEJDQqZ4m97H+xrFAxbW2j/+5g KjgS2zmQTiRpBxmCmJjDwuwRvvozTgKgv4NTEpqDRrEeaUNKTPJ6Zo7LpuDjexjwb1PT fjBQ== 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:dkim-signature:arc-authentication-results; bh=qEKueACvwjZr6nTROyIxt34gKgL4Oa/gNPjKkUPYbkM=; b=M0+2e5FvwKc1MaZ1UoMyWBsvt+8RyYh8pN+aYNH5eFlyzYouVxWNab2M20f7uKurC8 Io3W7uHs81atpe9psH93/yvH3JRFVSR6Vjk17X6TKTHssGJUCpQW5s/WBRmx42TaSzjj qZj5IU9mIDvCX9+3QWmTPP8x+MAlAiboBclut6Jz2xopRq90pMI/70JwENaeTj4Nhvdb GTO3U/DW1ygmpNXGIJW5xKiMvXOKZ1Q6a3SK/c6cPmX4UrnXWx4P2DVG8BW1CvQrNvmo jrA/EJKNnXzh3a71kE/7ZIQSGdgSVru0ARtLlGiIzIlAtbb+NTxj25W4rpGJhW0g6iGI 1pmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=MDq9Nwei; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w68-v6si19818683iof.116.2018.05.07.09.35.30; Mon, 07 May 2018 09:35:43 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=MDq9Nwei; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752623AbeEGQeq (ORCPT + 99 others); Mon, 7 May 2018 12:34:46 -0400 Received: from mail-lf0-f48.google.com ([209.85.215.48]:38309 "EHLO mail-lf0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbeEGQen (ORCPT ); Mon, 7 May 2018 12:34:43 -0400 Received: by mail-lf0-f48.google.com with SMTP id f18-v6so15902305lfc.5; Mon, 07 May 2018 09:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qEKueACvwjZr6nTROyIxt34gKgL4Oa/gNPjKkUPYbkM=; b=MDq9Nwei4Tbf6dnWhkD8ejdTV2k6hU5Jh25aRaUnVa38EDhuUcgGQSueX+D2lq8ZgL T7LZ8nTVfuwvSN4huh5+87UB8l/vKXdGMTucfwUIxy6rrzJL+RTF6lkB86LyrMDwpNaX hZYKW/Xt8zFGKO9MAsD5dwzr869xod1Hn8dba9S0vI4WD0ln9WvgBv4jg533w2gtQCM/ frZ5Rk/fZEiv91Zi1WuiuKx8RjAGqNWc6AwiReEysoaXoo9NNagrjig+ylL5WUwS2l0D MiHRubcvp9RWdOuTHCsNSdXDu0RE5RkQqfujm9CNgbmnQTptuSQER1xY04D1BZI0wmrZ tTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=qEKueACvwjZr6nTROyIxt34gKgL4Oa/gNPjKkUPYbkM=; b=aEK+tsEXe7aYiW5fQq2gkaV+BKO5kci1eS3ZXt2Z4JGXXqT8voG/OJk0qywf9jazeK 7roJzqLSzhqsvP/axnu2CXlvneZDpLMwqPKCfd3YJ83744phiPT0GwGbyCSN+YjvuLcx YJVJUA1FioaKxYLCrU+XPb9CXi+qOeR13pkyyEgI2xOOra+DfBVwflwM5e2iRr4XmfaO YVLLa5RrWkQxjICuqK2HCBUzCPIIMzEojsYrmMLXEw5bia4wkT00ONxHPmYTdUXXiD2z 6NQJzudKbs3rWL++yEQzYS96oThi3UNxnh9k3p3eFGMsMTax343OA4as8fYNyRwAialQ tesA== X-Gm-Message-State: ALQs6tAPhgZ9qXELufvrXsEzasaiob9RqA+8jw0PO2UEUqswLGWVvSLu +88VSQQ6zuEJRu2YQ0Z1qR4= X-Received: by 2002:a2e:4949:: with SMTP id b9-v6mr21418582ljd.116.1525710881521; Mon, 07 May 2018 09:34:41 -0700 (PDT) Received: from xi.terra (c-8bb2e655.07-184-6d6c6d4.cust.bredbandsbolaget.se. [85.230.178.139]) by smtp.gmail.com with ESMTPSA id i20-v6sm4250673lfe.69.2018.05.07.09.34.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 09:34:40 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.90_1) (envelope-from ) id 1fFj5z-0005R8-LN; Mon, 07 May 2018 18:34:39 +0200 Date: Mon, 7 May 2018 18:34:39 +0200 From: Johan Hovold To: Tony Lindgren Cc: Johan Hovold , 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: <20180507163439.GV2285@localhost> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180507154515.GP98604@atomide.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. > > 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 > > 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? > 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. 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. 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. Thanks, Johan