From patchwork Fri Feb 15 06:53:08 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 2144771 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 9C5723FCF6 for ; Fri, 15 Feb 2013 06:53:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161283Ab3BOGxT (ORCPT ); Fri, 15 Feb 2013 01:53:19 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:52836 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161118Ab3BOGxS (ORCPT ); Fri, 15 Feb 2013 01:53:18 -0500 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id r1F6rFJS020872; Fri, 15 Feb 2013 00:53:15 -0600 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id r1F6rFKv025051; Fri, 15 Feb 2013 00:53:15 -0600 Received: from dlelxv22.itg.ti.com (172.17.1.197) by dfle72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.1.323.3; Fri, 15 Feb 2013 00:53:15 -0600 Received: from localhost (h78-13.vpn.ti.com [172.24.78.13]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id r1F6rECC008484; Fri, 15 Feb 2013 00:53:15 -0600 Date: Fri, 15 Feb 2013 08:53:08 +0200 From: Felipe Balbi To: Tony Lindgren CC: Paul Walmsley , Felipe Balbi , Linux OMAP Mailing List , Linux ARM Kernel Mailing List Subject: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Message-ID: <20130215065308.GC30038@arwen.pp.htv.fi> Reply-To: References: <1360840554-26901-1-git-send-email-balbi@ti.com> <1360840554-26901-2-git-send-email-balbi@ti.com> <20130214171253.GC7144@atomide.com> <20130214175650.GA25891@arwen.pp.htv.fi> <20130214181217.GA11806@atomide.com> <20130214192719.GB26679@arwen.pp.htv.fi> <20130214193911.GD11806@atomide.com> <20130214222247.GE11362@atomide.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130214222247.GE11362@atomide.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Thu, Feb 14, 2013 at 02:22:47PM -0800, Tony Lindgren wrote: > * Paul Walmsley [130214 12:51]: > > Hi, > > > > On Thu, 14 Feb 2013, Tony Lindgren wrote: > > > > > I don't think so as hwmod should only touch the sysconfig space > > > when no driver has claimed it. > > > > hwmod does need to touch the SYSCONFIG register during pm_runtime suspend > > and resume operations, and during device enable and disable operations. > > Here's the relevant code: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod.c;h=4653efb87a2721ea20a9fe06a30a6c204d6d2282;hb=HEAD#l2157 > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod.c;h=4653efb87a2721ea20a9fe06a30a6c204d6d2282;hb=HEAD#l2195 > > But that's triggered by runtime PM from the device driver, right? > > I think it's fine for hwmod to do that as requested by the device > driver via runtime PM since hwmod is the bus glue making the drivers arch > independent. > > I think the only piece we're missing for that is for driver to run > something like pm_runtime_init() that initializes the address space > to hwmod. Or just bus specific ioremap like you're suggesting later > on. > > Just to recap what we've discussed earlier, the reasons why we want > reset and idle functions should be in the driver specific header are: > > 1. There's often driver specific logic needed in addition to the > syconfig tinkering in the reset/idle functions. how about introducing generic device_reset() and device_idle() hooks which driver can implement and can be called by bus glue ? Something like: We already have ->runtime_idle() which we could be using... > 2. We need to be able to reset and idle some hardware even if the > driver is not compiled in. yeah, this will be tricky. Even if you try late_initcall() there could still be issues with -EPROBE_DEFER. Maybe you don't need to reset the IPs but rather put those which have status = "disabled" to FORCE_IDLE. Wouldn't that be enough ? If a driver claims the device later, then pm_runtime_enable() + pm_runtime_get() will change that. diff --git a/include/linux/pm.h b/include/linux/pm.h index 03d7bb1..9c921e2 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -256,6 +256,8 @@ typedef struct pm_message { * these conditions and handle the device as appropriate, possibly queueing * a suspend request for it. The return value is ignored by the PM core. * + * @runtime_reset: Resets the device and puts it in a known state. + * * Refer to Documentation/power/runtime_pm.txt for more information about the * role of the above callbacks in device runtime power management. * @@ -285,6 +287,7 @@ struct dev_pm_ops { int (*runtime_suspend)(struct device *dev); int (*runtime_resume)(struct device *dev); int (*runtime_idle)(struct device *dev); + int (*runtime_reset)(struct device *dev); }; #ifdef CONFIG_PM_SLEEP