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, 26 Apr 2017 11:17:27 +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, 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. Which means that if you allow multiple entries in power-domains, we have to change drivers, DT bindings, and DTS again (which we may decide not to do ;-) On SH/R-Mobile, we always did it that way, as the user manual had an explicit "always-on" power domain. On R-Car Gen2, the power domains contain CPU and L2 and GPU only, so devices had their power-domains pointing to the clock controller. On R-Car Gen3, some devices were moved into power domains, so we generalized this by creating a virtual "always-on" power domain, and letting all devices point their power-domains properties to the power domain controller, which forwards clock handling to the clock controller. For consistency, this was applied to R-Car Gen2 as well. Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1 ('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'), but technically the fix was not needed, as it worked fine without. 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 S1435186AbdDZJ3B (ORCPT ); Wed, 26 Apr 2017 05:29:01 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:33224 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1961954AbdDZJR3 (ORCPT ); Wed, 26 Apr 2017 05:17:29 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490710443-27425-1-git-send-email-jonathanh@nvidia.com> From: Geert Uytterhoeven Date: Wed, 26 Apr 2017 11:17:27 +0200 X-Google-Sender-Auth: LtYndp3phHGdzVZNe21TIkdt47o 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, 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. Which means that if you allow multiple entries in power-domains, we have to change drivers, DT bindings, and DTS again (which we may decide not to do ;-) On SH/R-Mobile, we always did it that way, as the user manual had an explicit "always-on" power domain. On R-Car Gen2, the power domains contain CPU and L2 and GPU only, so devices had their power-domains pointing to the clock controller. On R-Car Gen3, some devices were moved into power domains, so we generalized this by creating a virtual "always-on" power domain, and letting all devices point their power-domains properties to the power domain controller, which forwards clock handling to the clock controller. For consistency, this was applied to R-Car Gen2 as well. Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1 ('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'), but technically the fix was not needed, as it worked fine without. 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