From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lina Iyer Subject: Re: [PATCH RFC 08/27] PM / Domains: Support IRQ safe PM domains Date: Mon, 18 Jan 2016 10:00:48 -0700 Message-ID: <20160118170048.GE1651@linaro.org> References: <1447799871-56374-1-git-send-email-lina.iyer@linaro.org> <1447799871-56374-9-git-send-email-lina.iyer@linaro.org> <20160114183316.GB1651@linaro.org> <20160115165758.GC1651@linaro.org> <20160118165818.GD1651@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Received: from mail-pf0-f179.google.com ([209.85.192.179]:33805 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755773AbcARRAw (ORCPT ); Mon, 18 Jan 2016 12:00:52 -0500 Received: by mail-pf0-f179.google.com with SMTP id q63so165168029pfb.1 for ; Mon, 18 Jan 2016 09:00:51 -0800 (PST) Content-Disposition: inline In-Reply-To: <20160118165818.GD1651@linaro.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Ulf Hansson Cc: Kevin Hilman , "linux-pm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Geert Uytterhoeven , Krzysztof =?utf-8?Q?Koz=C5=82owski?= , msivasub@codeaurora.org, Andy Gross , Stephen Boyd , "linux-arm-msm@vger.kernel.org" , Lorenzo Pieralisi , Axel Haslam , Marc Titinger , "Rafael J. Wysocki" On Mon, Jan 18 2016 at 09:58 -0700, Lina Iyer wrote: >On Fri, Jan 15 2016 at 15:08 -0700, Ulf Hansson wrote: >>[...] >> >>>>I think case 2 and case 3 should be okay to support, but I am really >>>>questioning case 1. >>>> >>>With you other patch, it does make sense to have 2 and 3 instead of 1 >>>and 2. >> >>Okay! >> >>>My only concern is as I view the SoC as a whole, there would be cases >>>where the parent domain could only be non-IRQ safe (turning off a big >>>regulator may require some sleep) and the subdomains are quicker and >>>faster IRQ-safe domains. Putting up this restriction, chops up the >> >>Just because they are "quick" (don't sleep) doesn't mean they have to >>set the IRQ safe flag for the domain. >> >>Let's compare how pm_runtime_irq_safe() is used for devices in >>drivers. Lots of corresponding runtime PM callbacks don't sleep, but >>that don't mean that the driver calls pm_runtime_irq_safe(). >> >>Drivers that are expecting to invoke pm_runtime_get_sync() (or other >>synchronous runtime PM API) from atomic context, requires the >>corresponding runtime PM callbacks to be IRQ safe. Only under these >>circumstances the pm_runtime_irq_safe() is used. >> >I agree. > >The limitation and the interpretation could completely be s/w. There is >nothing preventing that in hardware. So we could have a processor >subsystem domain that can collapse faster and even during cpuidle. We >would define that domain IRQ-safe because of its need to collapse and >resume when IRQs are disabled, but its parent may not have that >restriction, in fact, the parent could have another child that could >only operate as non-IRQ safe. > >By imposing the limitation that parents of IRQ-safe domains cannot be >non-IRQ-safe, we have to chop off that relationship, because of >another >non-IRQ-safe sibling. > >>>domain hierarchy. Imagine, if you could represent the whole power domain >>>organization in DT, but because of this restriction, we may not be able >>>to do that. >> >>You do have a point. Considering my comment above, do you still think >>this may become an issue? >> >Yes. Pls see my example below. > Sorry above ;) >That said, I probably won't encounter this limitation in my current >series, but its not hard to foresee this corner case. > >Thanks, >Lina