From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains Date: Wed, 3 May 2017 10:54:33 +0200 Message-ID: References: <1490710443-27425-1-git-send-email-jonathanh@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ulf Hansson Cc: Jon Hunter , "Rafael J . Wysocki" , Kevin Hilman , Rajendra Nayak , Stanimir Varbanov , Stephen Boyd , Marek Szyprowski , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-tegra@vger.kernel.org Hi Ulf, On Wed, May 3, 2017 at 8:43 AM, Geert Uytterhoeven wrote: > On Wed, Apr 26, 2017 at 11:55 AM, Ulf Hansson wrote: >> On 26 April 2017 at 11:17, Geert Uytterhoeven wrote: >>> On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson wrote: >>>> On 26 April 2017 at 10:06, Geert Uytterhoeven wrote: >>>>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson wrote: >>>>>> However, we currently know about at least two different SoCs that need >>>>>> this. Perhaps we can extend the below list to justify adding a new >>>>>> framework/APIs. Something along the lines what you propose in $subject >>>>>> patchset. >>>>>> >>>>>> 1) Nvidia; to solve the USB super-speed host/device problem. >>>>>> 2) QCOM, which has pointed to several cases where the PM topology is >>>>>> laid out like devices having two PM domains.. >>>>>> 3?) I don't fully remember - but I think Geert also pointed to some >>>>>> examples where a device could reside in a clock domain but also in >>>>>> power domain for a Renesas SoC!? >>>>>> 4) ? >>>>> >>>>> Most Renesas SoCs have module clocks, which we model as a clock domain. >>>>> Some Renesas SoCs have power domains for CPUs, others have them for >>>>> devices as well. >>>>> As we always provide a virtual "always-on" power domain in the power domain >>>>> controller, all devices can refer to it using "power-domains" properties, >>>>> and the driver for the power domain controller can just forward the clock >>>>> domain operations to the clock driver. >>>> >>>> Okay, thanks for clarifying this. >>>> >>>> Thinking about this as bit more, when I realized that *if* we would >>>> add a new PM domain framework for explicit control of PM domains, that >>>> would mean you need to deploy support for that in the drivers. >>> >>> Correct. And we have to update DT bindings and DTS. >>> >>>> On the other hand, as you anyway would need to change the drivers, you >>>> could instead deploy clock support in the drivers, which would avoid >>>> using the clock domain. In that way, you could still stay with one PM >>>> domain pointer per device, used to control the power domains instead. >>>> Right? Or would that have other implications? >>> >>> That's exactly what we're doing already. >> >> No really, but perhaps I was not clear enough. >> >> Currently you deploy only runtime PM support in the driver and don't >> do any clk_get() etc. Then you have a PM domain (genpd) attached to Note that drivers that care about clock properties do use clk_get(). E.g. an SPI controller driver needs to know the clock rate to program its internal divider to drive external SPI slaves. >> the device and makes use of genpd's device specific callbacks, in >> struct gpd_dev_ops ->start|stop(), which allows you to control clocks >> for each device. Of course this is perfectly okay. > > OK. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752525AbdECIym (ORCPT ); Wed, 3 May 2017 04:54:42 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:36118 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbdECIyf (ORCPT ); Wed, 3 May 2017 04:54:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490710443-27425-1-git-send-email-jonathanh@nvidia.com> From: Geert Uytterhoeven Date: Wed, 3 May 2017 10:54:33 +0200 X-Google-Sender-Auth: 3GNK_D8VkmZfllGeAcvDhhICxmw Message-ID: Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains To: Ulf Hansson Cc: Jon Hunter , "Rafael J . Wysocki" , Kevin Hilman , Rajendra Nayak , Stanimir Varbanov , Stephen Boyd , Marek Szyprowski , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ulf, On Wed, May 3, 2017 at 8:43 AM, Geert Uytterhoeven wrote: > On Wed, Apr 26, 2017 at 11:55 AM, Ulf Hansson wrote: >> On 26 April 2017 at 11:17, Geert Uytterhoeven wrote: >>> On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson wrote: >>>> On 26 April 2017 at 10:06, Geert Uytterhoeven wrote: >>>>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson wrote: >>>>>> However, we currently know about at least two different SoCs that need >>>>>> this. Perhaps we can extend the below list to justify adding a new >>>>>> framework/APIs. Something along the lines what you propose in $subject >>>>>> patchset. >>>>>> >>>>>> 1) Nvidia; to solve the USB super-speed host/device problem. >>>>>> 2) QCOM, which has pointed to several cases where the PM topology is >>>>>> laid out like devices having two PM domains.. >>>>>> 3?) I don't fully remember - but I think Geert also pointed to some >>>>>> examples where a device could reside in a clock domain but also in >>>>>> power domain for a Renesas SoC!? >>>>>> 4) ? >>>>> >>>>> Most Renesas SoCs have module clocks, which we model as a clock domain. >>>>> Some Renesas SoCs have power domains for CPUs, others have them for >>>>> devices as well. >>>>> As we always provide a virtual "always-on" power domain in the power domain >>>>> controller, all devices can refer to it using "power-domains" properties, >>>>> and the driver for the power domain controller can just forward the clock >>>>> domain operations to the clock driver. >>>> >>>> Okay, thanks for clarifying this. >>>> >>>> Thinking about this as bit more, when I realized that *if* we would >>>> add a new PM domain framework for explicit control of PM domains, that >>>> would mean you need to deploy support for that in the drivers. >>> >>> Correct. And we have to update DT bindings and DTS. >>> >>>> On the other hand, as you anyway would need to change the drivers, you >>>> could instead deploy clock support in the drivers, which would avoid >>>> using the clock domain. In that way, you could still stay with one PM >>>> domain pointer per device, used to control the power domains instead. >>>> Right? Or would that have other implications? >>> >>> That's exactly what we're doing already. >> >> No really, but perhaps I was not clear enough. >> >> Currently you deploy only runtime PM support in the driver and don't >> do any clk_get() etc. Then you have a PM domain (genpd) attached to Note that drivers that care about clock properties do use clk_get(). E.g. an SPI controller driver needs to know the clock rate to program its internal divider to drive external SPI slaves. >> the device and makes use of genpd's device specific callbacks, in >> struct gpd_dev_ops ->start|stop(), which allows you to control clocks >> for each device. Of course this is perfectly okay. > > OK. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds