Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755154AbbLDNGf (ORCPT ); Fri, 4 Dec 2015 08:06:35 -0500 Received: from mga02.intel.com ([134.134.136.20]:4004 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754197AbbLDNGX (ORCPT ); Fri, 4 Dec 2015 08:06:23 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,380,1444719600"; d="scan'208";a="864639826" Subject: Re: [PATCH v2 2/7] ACPI / LPSS: allow to use specific PM domain during ->probe() To: "Shevchenko, Andriy" , "rjw@rjwysocki.net" References: <1448551153-84719-1-git-send-email-andriy.shevchenko@linux.intel.com> <565733A2.6050900@linux.intel.com> <1448556317.15393.77.camel@linux.intel.com> <10907323.ZOUAMFPIfU@vostro.rjw.lan> <1448618173.15393.104.camel@linux.intel.com> <1449171008.15393.158.camel@intel.com> Cc: "Koul, Vinod" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "dmaengine@vger.kernel.org" , "mika.westerberg@linux.intel.com" , "gregkh@linuxfoundation.org" , "linux-acpi@vger.kernel.org" From: Jarkko Nikula Message-ID: <56618F47.9080205@linux.intel.com> Date: Fri, 4 Dec 2015 15:04:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 MIME-Version: 1.0 In-Reply-To: <1449171008.15393.158.camel@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1192 Lines: 30 On 12/03/2015 09:29 PM, Shevchenko, Andriy wrote: > I briefly checked this for DMA issue. It will not help anyhow, so we > *have to* move a power domain assignment to the BIND stage. > > For I2C and rest LPSS devices this might help (though didn't look > deeply). My understanding that we assign those callbacks in the LPSS > custom PM domain and call them explicitly in acpi_lpss.c. > > The code will be the same as we are using now to bring device from > runtime suspend resume. This means whenever we call probe for e.g. I2C > we end up in a sequence similar to: > pm_runtime_resume(I2C); > ->probe(I2C); > pm_runtime_suspend(I2C); > > I will try to mock up this and check if it will work, though have no > idea what to do if I2C during probe calls pm_runtime_forbid(). > > Jarkko, what do you think? > I suppose device core will handle it. If the runtime PM is forbidden or not initialized at all the device shouldn't idle. -- Jarkko -- 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/