Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1041755pxk; Fri, 25 Sep 2020 04:52:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3BzSBBLGa7vyukNztZxJ4X88iabnMOIWVprj7jODOrUz3gCFahkFhm2bJdnPnSQuI+lds X-Received: by 2002:aa7:c1c3:: with SMTP id d3mr900152edp.228.1601034775645; Fri, 25 Sep 2020 04:52:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601034775; cv=none; d=google.com; s=arc-20160816; b=qhJhSa8XLHNC6kVozaXNT+iSpHhuKkcWS7cTQuf0tRFts6wAPhe/yBoPyIvrK9oJRf MdHL5lqwD0HdWUfOwILFZX58X3Uume3J9bT3s/dr8+XduMPxcl9YUbUjgcWphGBNki8S 32M+mjasZq3QJWHLei8kcnZMqmNiaCkbyQQubiBonrCpeTLjD1/UXcJPYcuQRRWiOWAj vbKcX8XPFv8bpX8hDPVn+D41feU1yLh8CyAAWKl4e94Ik6T56u0jrkypxJWbPDhQFfnu sM2onglO7GDpqG9cU9zGLpCK9JFJq44IIkLAT6P3vSaqNBKnj48HY33YGLH1QSbxd6Ah gtkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=bOpX08TIm3AOFTz7k77ObUqDMIC27zNLgskbqhvk3SA=; b=0oedtJrfXOj2FIilbYSTYWr7PMOIjncTh5I90HpdDw0fu3iZtZ9UlK39QB5LKnZUFP LL29ffet0iR8zTv0bxJhDKlz3kfbUJ8HdhNcVfHf7eNqI0yDhFPu1JOQ/26X0mgnZuhl sKWdQ4rhWiSKjOhiOjTXM+3GD5AAg9y4Q9HQA0ErXhDqjETIIEiHHupBr9zQu+3+4H5U hu/HjVoGyf/dRjV4cGMLDwjF3Q8YFsVc2bc1XkdHtvPoxYfo8jJHzkc+dBA2Xf2ipTu6 y4HlJ2wbV+8Y6H/EhZEG1I9h/kAm8pVMDB07QcRol7eckFjj2PjdUYSQBruc9ZB6Jw+6 zNsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PACLZu7q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si1925315edj.252.2020.09.25.04.52.31; Fri, 25 Sep 2020 04:52:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PACLZu7q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728244AbgIYLst (ORCPT + 99 others); Fri, 25 Sep 2020 07:48:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727290AbgIYLst (ORCPT ); Fri, 25 Sep 2020 07:48:49 -0400 Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32619C0613CE for ; Fri, 25 Sep 2020 04:48:49 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id b4so560879vkh.9 for ; Fri, 25 Sep 2020 04:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bOpX08TIm3AOFTz7k77ObUqDMIC27zNLgskbqhvk3SA=; b=PACLZu7q59wk8Az8cg9u6s88T2SjRUmZWHyp1N0U0G5a3NhuafqvY+nnQIz4jwHzKZ JdBWjVnR7lTpQMYe2ucg7FDdeN/XtVwC0R4lDX/2qDcHquqOeS5NcREMzCelxwmfg3Fr sBd4sxyvhLLvFYfYzJn4MuyMj7JmUkd8TgbCDts23DFzsE9FoEnTOlgEnGv5My0efX/W 9pCVtYMYG4HCYJOp6GbENz2C1YSDG/yNY336BmDJ/O1JvxhGKG5wnAV/79fqZeH1/R48 MTOLEI+oQyeoDTH0YRQ0w7GfXXDXa1WaR06bv3F1Hjw86Fbmd4YNU3PRUWTH8B0YZ95y PtTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bOpX08TIm3AOFTz7k77ObUqDMIC27zNLgskbqhvk3SA=; b=soFZXBCHBAD1OT0KApeCx2bsrBBG9h0o1wPtPsxF5LUHSy0OG91wh35oOOdNiA2niz kbfL8P2IpwXbudzQgcBUycaLrLQmnbO6A4vXN9Z2GfJl1xcvsf6n/BX4/F+GO9VEKamc Z4KZoJPEjrpqsG56eueocy+wtZ5bOMLl/w2TxNtyNHyma9xf1w93EaKP8DYa4Tg3nsuf smQ7UGaer9qZQIlaXMWexTqoFGJ4KuqdwSZzcd11FfnR5Y9gDgjTqoDonZd7sl5saRZi 7uDYIQWnEgOQsRZJ8lQgomjXr0JXTFffOiEAkULWBAvvFy49hoMHF+bFmSaSVJiU7YB2 206g== X-Gm-Message-State: AOAM5324k0lPHatdOoR7txcw+pB9TqjfbgXcczEgmwnmmdT/1A2AkMM2 gnyjS2SIcSdgFfKcMBD2KmS6rOimuYsEiYqQZDz1rQ== X-Received: by 2002:a1f:964c:: with SMTP id y73mr2404723vkd.8.1601034528439; Fri, 25 Sep 2020 04:48:48 -0700 (PDT) MIME-Version: 1.0 References: <20200924110449.329523-1-ulf.hansson@linaro.org> <20200924110449.329523-4-ulf.hansson@linaro.org> In-Reply-To: From: Ulf Hansson Date: Fri, 25 Sep 2020 13:48:12 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] PM / Domains: Add support for PM domain on/off notifiers for genpd To: Peng Fan Cc: "Rafael J . Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Sudeep Holla , Lorenzo Pieralisi , Daniel Lezcano , Lina Iyer , Lukasz Luba , Vincent Guittot , Stephen Boyd , Bjorn Andersson , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Sep 2020 at 08:08, Peng Fan wrote: > > Hi Ulf, > > > Subject: [PATCH v2 3/3] PM / Domains: Add support for PM domain on/off > > notifiers for genpd > > > > A device may have specific HW constraints that must be obeyed to, before its > > corresponding PM domain (genpd) can be powered off - and vice verse at > > power on. These constraints can't be managed through the regular runtime > > PM based deployment for a device, because the access pattern for it, isn't > > always request based. In other words, using the runtime PM callbacks to deal > > with the constraints doesn't work for these cases. > > Could the notification be added before/after power on, and before/after power > off? not just after power on and before power off? > > Our SoC has a requirement that before power on/off the specific module, > the corresponding clk needs to be on to make sure the hardware async > bridge could finish handshake. Thanks for your comments! May I ask, to be sure - does the clock correspond to the genpd provider or is it a clock for the genpd consumer device? If the former, couldn't the clock be managed from the ->power_on|off() callbacks for the genpd provider? > > So we need clk_prepare_on/off to guard power on and power off as below: > > clk_prepare_on > power on > clk_prepare_off > > clk_prepare_on > power off > clk_prepare_off > > Thanks, > Peng. > [...] Kind regards Uffe