Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757438AbaKTVyM (ORCPT ); Thu, 20 Nov 2014 16:54:12 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:62135 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756817AbaKTVyJ (ORCPT ); Thu, 20 Nov 2014 16:54:09 -0500 MIME-Version: 1.0 In-Reply-To: <7hbno1r1af.fsf@deeprootsystems.com> References: <1415631557-22897-1-git-send-email-grygorii.strashko@ti.com> <1709760.E0jX3Myv0h@wuerfel> <546C7FDD.7030906@ti.com> <2900095.WIocOu7ue2@wuerfel> <546DD87B.3080806@ti.com> <546E0970.5090301@ti.com> <7hh9xtr5ac.fsf@deeprootsystems.com> <7hbno1r1af.fsf@deeprootsystems.com> Date: Thu, 20 Nov 2014 22:54:07 +0100 X-Google-Sender-Auth: 2_n2FoGtXMETnDuKSmVQ1g5atko Message-ID: Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains From: Geert Uytterhoeven To: Kevin Hilman Cc: Grygorii Strashko , Ulf Hansson , Arnd Bergmann , ssantosh@kernel.org, "Rafael J. Wysocki" , "linux-pm@vger.kernel.org" , Rob Herring , Grant Likely , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Dmitry Torokhov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 20, 2014 at 10:48 PM, Kevin Hilman wrote: >>> So what exactly are we talking about with "PM" clocks, and why are they >>> "special" when it comes to PM domains? IOW, why are the clocks to be >>> managed during PM domain transitions for a given device any different >>> than the clocks that need to be managed for a runtime suspend/resume (or >>> system suspend/resume) sequence for the same device? >> >> (Speaking for my case, shmobile) >> >> They're not. The clocks to be managed during PM domain transitions are the >> same as the clocks that need to be managed for a runtime suspend/resume >> (or system suspend/resume) sequence. >> >> The special thing is that this is more a platform than a driver thing: the same >> module may have a "PM/functional" clock (that is documented to enable/disable >> the module) on one Soc, but noet on another. > > So why isn't the presence or absence of the clock described in the .dtsi > for the SoC instead of being handled by special PM domain logic? It is. Cfr. the presence/absence of clocks for renesas,rcar-gpio nodes. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/