From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [POWER DOMAIN suspend callbacks] Observation. Date: Wed, 24 Aug 2011 16:38:01 -0700 Message-ID: <874o167546.fsf@ti.com> References: <4E53B6FC.8030507@ti.com> <871uwcjbwi.fsf@ti.com> <4E549769.2030800@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog111.obsmtp.com ([74.125.149.205]:59035 "EHLO na3sys009aog111.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054Ab1HXXiG (ORCPT ); Wed, 24 Aug 2011 19:38:06 -0400 Received: by mail-yi0-f48.google.com with SMTP id 17so1612807yib.21 for ; Wed, 24 Aug 2011 16:38:05 -0700 (PDT) In-Reply-To: <4E549769.2030800@ti.com> (Santosh's message of "Wed, 24 Aug 2011 11:47:13 +0530") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Santosh Cc: "Rafael J. Wysocki" , Linux PM mailing list , linux-omap@vger.kernel.org, Govindraj R Santosh writes: > On Tuesday 23 August 2011 10:36 PM, Kevin Hilman wrote: >> Hi Santosh, >> >> Santosh writes: >> >>> Rafael, Kevin, >>> >>> On latest kernel( V3.1-rc1+), the subsystem(driver) suspend >>> callbacks are not getting called because power domain callbcaks >>> are populated. >>> >>> And as per commit 4d27e9dc{PM: Make power domain callbacks take >>> precedence over subsystem ones}, it's expected bahavior. >> >> Correct. >> >>> Who is suppose to call the driver suspend callback? >> >> If populated, the PM domain callbacks should call the driver callbacks. >> If there are no PM domain callbacks, then the subsystem (in this case, >> the platform_bus) should be calling the driver callbacks. >> >>> Some drivers/subsystem would have state machine which needs to >>> be suspended. >>> >>> Is the power domain suspend callback, suppose to take care of >>> it ? If yes, then that seems to be missing for OMAP. >> >> Yup, there's a bug. They're not missing, just misplaced. ;) >> >> When adding the noirq callbacks to ensure devices are idled late in >> suspend by omap_device, I the patch commited mistakenly uses >> SET_SYSTEM_SLEEP_PM_OPS(), which sets the "normal" suspend/resume >> handlers and not the noirq handlers. >> >> Can you try the patch below? I only briefly tested it on omap3/n900 so >> far. >> > The patch works like charm. Thanks, I'll add a tested-by for you. Kevin