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 09:58:18 -0700 Message-ID: <20160118165818.GD1651@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Received: from mail-pa0-f42.google.com ([209.85.220.42]:33202 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755791AbcARQ6X (ORCPT ); Mon, 18 Jan 2016 11:58:23 -0500 Received: by mail-pa0-f42.google.com with SMTP id cy9so436743054pac.0 for ; Mon, 18 Jan 2016 08:58:22 -0800 (PST) Content-Disposition: inline In-Reply-To: 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 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. That said, I probably won't encounter this limitation in my current series, but its not hard to foresee this corner case. Thanks, Lina