Received: by 10.192.165.148 with SMTP id m20csp5279969imm; Wed, 9 May 2018 02:19:44 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpONX0Dv9WXzLrchez/A1ifo3KpwmzKxy1BGiiWa8wve7rmMDQ7vdGQKu9WmzJ9ksK5hP9M X-Received: by 2002:a63:79ce:: with SMTP id u197-v6mr35960751pgc.242.1525857584011; Wed, 09 May 2018 02:19:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525857583; cv=none; d=google.com; s=arc-20160816; b=GNMrLtJ9RxWWQobgtuDs/kNBQR7HmvXpOnxJGx543toOx7aGrgKd6CB+40YUQdt7r3 YieY7eOXW3IJtjXWwtXfn7Zb/smVMvjXkYdWdlTbk3XMsO8kIhaiopmDOfPypmF8+j/j fGoK9pRuy5FGzO6s/x6+rqnVUkB5SAkjkPOZNxxuRN31F2OxsoFFIa7UJR7aDnu3pBPM BG/6qPPQ2E7VIQ3Y0CMX4UjhpCuO1p6HPMjSwU8IZ8Yn3+GZPof8FUrVJSNDCMJ55gnd WAtkPn7VUTMQyOkc9xSj7pJlSo9rr0ZugknvX9FfQxVCzNkUU33iy/yPWmeBLpK/iWhS EIxg== 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=iFjN9cb6vBbD5PDJy/gD+uXgE74Nwj0Qh4wb0yyOsNE=; b=M2TkgJfnIvfkR/6BqC99zZGOikCjBBJTvMvpO0F+8wG4rRJ3UNFGeIFW0hC6Ee9ZsQ +1gCQPNhXCKWlVJVPR74mswMk4b6+vxDD6WdwxyLVRVUhxhb9fXbHREJaAJiCx/EbwzC D3Y11foTjnJaSmAlL8sBvo3U8v2r3nLpWLvc7U+1pCyGlkvwnKRo/3fIqT8smvBBx85T CGswL7HOPD5jNdjmCOmfWc/pdJIZweySIsRGccU97OrYEG0rx+IzTZpUTJhgu9wyid5q CJ8HLn7wYJCcJJlbEI+Vzz4H9CSIrdGmx6+PXzeFu8M4ZxQBVIclOLKK8MgCzrYoWYMR LhJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=l6cnpKl3; 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 w10si26359965pfg.174.2018.05.09.02.19.29; Wed, 09 May 2018 02:19: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=l6cnpKl3; 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 S934643AbeEIJSm (ORCPT + 99 others); Wed, 9 May 2018 05:18:42 -0400 Received: from mail-lf0-f53.google.com ([209.85.215.53]:35552 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934607AbeEIJSe (ORCPT ); Wed, 9 May 2018 05:18:34 -0400 Received: by mail-lf0-f53.google.com with SMTP id y72-v6so36167036lfd.2; Wed, 09 May 2018 02:18:33 -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=iFjN9cb6vBbD5PDJy/gD+uXgE74Nwj0Qh4wb0yyOsNE=; b=l6cnpKl3jocPDRsAtHqbZFFtwz2NxU4+fRwsqJA1GZhgDcmgFKDu2HcI6+rNAO5mw7 zKnfWbKBoiRwiR041P1M3hsKSycwwlioepuHmaSEK+/KTepnokkEsJzaFggFa4/WDX8e nNjgHdpncYpTAly3LyLkVCc7TwJzipHhBD0hmq6Wj6n8hqELTiJgI+Xrnr8p3Wyk2mIM 6O2VHNAGuCAOIzVe6pU4qjkqC6ml5R/1LfHAee+OtaR1U+xKPsot8DDeKNi6u+Eujjpf LERcpIpPa30+6YGy06VdhO0k3IKD+TEnB0Y17hH7K4IoI6GG1G+CmeiHrdNM7YQfyGfw G4lw== 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=iFjN9cb6vBbD5PDJy/gD+uXgE74Nwj0Qh4wb0yyOsNE=; b=kUfcRkuiu6IsO5gYwxw4VcGeR5awmrJxlnit0RHqqHk1w/L+5CnqM6XE+v8asyMVfn Keuzfw15np0UUL6qXplt8NcwnkFMqWF/IJwhFRgqIB+b2biE5926mGMSbOyKvc6rXbno i4naAvtDrSuYMLnDOs/2d6fJu5yiTq1vud0v/3MbevzmxAN6zZcedzml5aWkSdgPgKDG BkpRdUukRat0SQxZnQmfk9p+FvL1pmrV7+AP69GUzhdG9k/nCdn3hJ1izFT55SO3lvC/ hoBsvfN+PBhfEqaqX3vXMP6JwulWm6c1fLDnB6SmU8+EQLxZGmbkamlRzKVEXWRIpeyE cliA== X-Gm-Message-State: ALQs6tCQ3DIQ+v7rbeuof+gsQEvCgJ2jVI5TC7HyUmGAQStq3OYlcW9n GT1dcjEukqPns2ypS2M2D+k= X-Received: by 2002:a2e:760a:: with SMTP id r10-v6mr29653366ljc.144.1525857512406; Wed, 09 May 2018 02:18:32 -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 d127-v6sm83155lfe.14.2018.05.09.02.18.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 02:18:31 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.90_1) (envelope-from ) id 1fGLF1-0003CR-LS; Wed, 09 May 2018 11:18:32 +0200 Date: Wed, 9 May 2018 11:18:31 +0200 From: Johan Hovold To: Sebastian Reichel Cc: Johan Hovold , Tony Lindgren , "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 , linux-serial@vger.kernel.org, linux-pm@vger.kernel.org Subject: Serdev runtime PM (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding) Message-ID: <20180509091831.GA2285@localhost> References: <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> <20180508155608.3bzcbepsmoskhlox@earth.universe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180508155608.3bzcbepsmoskhlox@earth.universe> 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 [ Changing the subject line as this is thread is no longer about DT bindings. Also adding linux-serial and linux-pm while keeping some context. ] On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote: > Hi, > > On Mon, May 07, 2018 at 06:34:39PM +0200, Johan Hovold wrote: > > On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote: > > > * 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. > > I think using open/close for runtime pm is good enough for GPS, > since it regularly sends data and draws lots of power anyways. > But devices, that have an out-of-band wakeup signal can do proper > runtime PM of the serial port without loosing characters. Yeah, there may be some applications where this is possible. And this is not the case for GPS, but not just because of a generally higher power consumption, but due to the fact that we cannot afford having the first message in every report burst be dropped. > Note, that OMAP does not reach deep idle states with active > serial port. This is not acceptable for low power devices. Sure, but note that OMAP is the only serial driver which currently implements this kind of aggressive runtime PM (besides a couple of usb-serial drivers). This means that a serdev driver can never rely on this being the case, and therefore needs to be restrictive about how long the port is kept open if it cares about power at all. > > > > 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. > > For I2C/SPI this works, since receive operations are initiated by > the controller. Unfortunately its harder to implement for async > serial. But I agree, that we may want to have runtime PM for the > serdev client and .ignore_children is the way to go. It's really about adding runtime PM support to serdev controllers. Serdev client drivers can already use runtime PM (as mentioned above). The ignore_children flag would then allow the controller RPM state to be managed independently of the child/slave device state when more fine grained RPM control is desired. > I think the client API should allow two things: > > 1. minimal runtime PM support: The controller is runtime enabled > on serdev open and disabled on serdev close. This may be enough > for some clients and useful for writing new drivers. Right, and we already have something like this today by means of how the serial driver implement runtime PM (i.e. they are generally active while the port is open). > 2. full runtime PM support: The controller is sleeping by default > even with serdev open. The calls to write/change port settings/... > automatically enables the device, similar to i2c/spi. But there > must be additional functions to enable/disable runtime PM based > on a wakeup gpio or similar out-of-band information. It may be > enough to just provide: > > int serdev_pm_runtime_get_sync(struct serdev_device *serdev) { > pm_runtime_get_sync(&serdev->dev); > } > > int serdev_pm_runtime_put_autosuspend(struct serdev_device *serdev) { > pm_runtime_put_autosuspend(&serdev->dev); > } I'm not a big fan of rpm wrappers and prefer using the RPM interface directly, but that's a side note. In the above case we really want to manage the controller (&serdev->ctrl->dev) rather than the client however (.ignore_children should be set, remember). Also note that a serial driver implementing aggressive RPM (e.g. using autosuspend) would manage the RPM counts itself when changing terminal settings etc, so the only thing that would be needed is for the client/slave device to resume the controller pro-actively when it is expecting incoming data. To make this more concrete; an example could be a device with an OOB wake-up signal, but using a request-response type protocol so that the client driver knows when it's safe to allow the controller to again suspend. We can model this similarly to how we do it for usb-serial, namely that the core takes an extra RPM reference at open, which a sufficiently power aware driver can then chose to drop in order to allow for more aggressive controller runtime PM (should the underlying device and driver support it). I've cooked up a patch which I'll be sending as a reply to this mail. Thanks, Johan