Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759195Ab2KANWS (ORCPT ); Thu, 1 Nov 2012 09:22:18 -0400 Received: from mail-ea0-f174.google.com ([209.85.215.174]:33793 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756264Ab2KANWN (ORCPT ); Thu, 1 Nov 2012 09:22:13 -0400 MIME-Version: 1.0 In-Reply-To: <874nl9tuqq.fsf@deeprootsystems.com> References: <1350911580-20307-1-git-send-email-sourav.poddar@ti.com> <20121024161429.GA16350@core.coreip.homeip.net> <4099134.xWUIfbbahk@dtor-d630.eng.vmware.com> <20121030113407.GA24335@sirena.org.uk> <87obji8kta.fsf@deeprootsystems.com> <874nl9tuqq.fsf@deeprootsystems.com> Date: Thu, 1 Nov 2012 14:22:11 +0100 Message-ID: Subject: Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support From: Linus Walleij To: Kevin Hilman Cc: Arnd Bergmann , Olof Johansson , Mark Brown , Dmitry Torokhov , Felipe Balbi , Benoit Cousson , Sourav Poddar , tony@atomide.com, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2397 Lines: 61 On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman wrote: > [Me] >> Well, the pinctrl grabbers in these drivers are using these states also >> for platforms that do not even select CONFIG_PM. For example >> mach-nomadik is quite happy that the PL011 driver is thusly >> muxing in its pins. And would require refactoring to use PM >> domains. > > If CONFIG_PM is disabled, then is it safe to assume that the pins in > question are probably only done once at init time. I assume during > ->probe(). ? Sadly no. Consider drivers/tty/serial/amba-pl011.c Many ARM platforms have several instances of PL011, and not all of them have CONFIG_PM & friends, so it's a good example. Here the driver will probe and currently fetch a pinctrl handle and looks up two states: "default", which refers to the situation you describe, and optionally "sleep" which will put pins into a low-power state. The driver will currently put the pins into the "sleep" state when .shutdown() is called by something (userspace or in-kernel users). So in the new suggested scheme using runtime PM, this would have to be replaced by pm_runtime_get[_sync]() and pm_runtime_put() hints and the current pin handling deleted, and for each platform using this driver instead implement a PM domain to do the same thing. Else you loose this runtime power optimization. This is what I refer to the all-or-nothing charcter of runtime PM domains... but maybe it's a good thing, I haven't quite made my mind up about it. > (...) if what we want/need are only ways to introduce SoC-specific > integration details into non-PM transitions (e.g. probe/remove), maybe > bus notifiers would suffice here. e.g. you'd get a bus notifier when > the device is added/attached and any init-time pinctrl setup could be > done then. This still keeps drivers clean of SoC-specific integration > data/code, and also allows that to happen whether or not PM features are > enabled. It doesn't cut it for any of our drivers as shown above, but it would work for the patch in $SUBJECT. It sounds like the way silicon clocks are handled on SH am I right? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/