From: Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Cc: Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
"linux-pm@vger.kernel.org"
<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel@vger.kernel.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree@vger.kernel.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains
Date: Fri, 21 Nov 2014 11:29:53 -0800 [thread overview]
Message-ID: <7hsihcmjwu.fsf@deeprootsystems.com> (raw)
In-Reply-To: <546F8B39.1080106-l0cyMroinI0@public.gmane.org> (Grygorii Strashko's message of "Fri, 21 Nov 2014 20:58:01 +0200")
Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org> writes:
> Hi Kevin,
> On 11/21/2014 10:06 AM, Geert Uytterhoeven wrote:
>> On Fri, Nov 21, 2014 at 2:30 AM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> writes:
>>>> On Thu, Nov 20, 2014 at 10:48 PM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 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.
>>>
>>> Hmm, OK, Good.
>>>
>>> So now I'm confused about why the PM domain has to do anything special
>>> if the presence/absence of the clocks is already handled by the DT.
>>
>> Just adding a clock property to a device node in DT doesn't enable the clock
>> automatically, nor make it runtime-managed automatically.
>> Compare this to e.g. pinctrl, where adding pinctrl properties to DT does enable
>> them automatically, without the driver for the device having to care about it.
>>
>> Drivers interfacing external hardware typically do care about clocks, as they
>> have to program clock generators for the external hardware interface (e.g.
>> driving spi or i2c buses at specific frequencies).
>>
>> Other random drivers don't care about clocks, so they don't handle them.
>> But as long as they make basic pm_runtime_{enable,get_sync,put}() calls,
>> the (optional) clocks (and hardware PM domains) will "work" fine, if handled
>> by the PM (clock) domain.
>
> Personally, I don't see problems with "functional" clocks.
> The problem, in my opinion, is that we can't specify in DT that some clock is
> "optional", so no one should touch such clock except driver.
> For example:
> Keystone 2 NETCP module has 3 clocks:
> clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
> clock-names = "clk_pa", "clk_cpgmac", "cpsw_cpts_rft_clk";
> and CPTS functionality is optional (in general) and can be enabled/disabled.
> Also, usual example is MMC hosts
> - OMAP hsmmc has "functional" clock "hsmmc1_fclk", and may have
> "optional" clock "mmchsdb_fck". As you may remember, PM runtime
> for OMAP2+ implemented by OMAP PM domain which performs many things,
> but one thing which is done always is enabling/disabling of "fck"
> when get/put() are called.
>
> Actually, pm_clk is very simple case of OMAP PM domain which should only
> handle clocks.
>
> In non-DT case, we have possibility to divide clocks on "fck" and "opt"
> (The way it can be done is not convenient, but it is - .con_id).
>
> For DT-case - no way now. Also, PM domains are not physically present on
> Keystone 2 and GPD was selected as glue layer to integrate DT, pm_clk and
> PM runtime all together (one big-fat-global PM domain :).
>
> So, I was able to find only following way to define "fck" clocks in DT:
> clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
> clock-names = "clk_pa", "clk_cpgmac", "cpsw_cpts_rft_clk";
> fck-clocks = <&papllclk>, <&clkcpgmac>;
> As you can see - this will lead to data duplication in DT (
>
> Any propositions are welcome?
How about you proposed a new (optional) property for the clock bindings
called 'clocks-optional' or something like that. The clock maintainer
(Mike Turquette, Cc'd) is also very familiar with OMAP and the need for
these different kinds of clocks.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-11-21 19:29 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-10 14:59 [PATCH v4 0/2] ARM: keystone: pm: switch to use generic pm domains Grygorii Strashko
2014-11-10 14:59 ` [PATCH v4 1/2] " Grygorii Strashko
2014-11-10 15:06 ` Arnd Bergmann
2014-11-10 17:38 ` Grygorii Strashko
2014-11-10 20:36 ` Arnd Bergmann
2014-11-17 19:14 ` Kevin Hilman
[not found] ` <7h389h3aif.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2014-11-17 20:37 ` Arnd Bergmann
2014-11-17 21:50 ` Kevin Hilman
2014-11-18 18:54 ` Grygorii Strashko
2014-11-18 19:32 ` Arnd Bergmann
2014-11-19 11:32 ` Grygorii Strashko
2014-11-19 13:47 ` Arnd Bergmann
2014-11-20 11:34 ` Ulf Hansson
2014-11-20 12:03 ` Grygorii Strashko
2014-11-20 13:12 ` Ulf Hansson
2014-11-20 13:32 ` Geert Uytterhoeven
2014-11-20 15:32 ` Grygorii Strashko
2014-11-20 20:22 ` Kevin Hilman
2014-11-20 20:26 ` Geert Uytterhoeven
2014-11-20 21:48 ` Kevin Hilman
2014-11-20 21:54 ` Geert Uytterhoeven
[not found] ` <CAMuHMdVXGPu7x706NxqO3rn3KuRbPbD_ZQsJtDH4Hf31AaRR+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 1:30 ` Kevin Hilman
[not found] ` <7hppchpcfm.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2014-11-21 8:06 ` Geert Uytterhoeven
2014-11-21 18:58 ` Grygorii Strashko
[not found] ` <546F8B39.1080106-l0cyMroinI0@public.gmane.org>
2014-11-21 19:29 ` Kevin Hilman [this message]
2014-11-21 20:14 ` Grygorii Strashko
2014-11-24 10:50 ` Arnd Bergmann
2014-11-25 6:44 ` Mike Turquette
2014-11-25 10:33 ` Arnd Bergmann
2014-11-25 11:08 ` Grygorii Strashko
[not found] ` <54746349.3000306-l0cyMroinI0@public.gmane.org>
2014-11-25 12:09 ` Arnd Bergmann
2014-11-25 13:30 ` Grygorii Strashko
2014-11-25 14:04 ` Russell King - ARM Linux
2014-11-25 14:53 ` Grygorii Strashko
2014-11-25 16:28 ` santosh shilimkar
[not found] ` <CAMuHMdU6G35SP-P7bt6RJQk59CrGcKE2XM4N3o8Dv3qxZU7gxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 19:20 ` Kevin Hilman
[not found] ` <546E0970.5090301-l0cyMroinI0@public.gmane.org>
2014-11-21 9:04 ` Geert Uytterhoeven
2014-11-18 2:18 ` santosh.shilimkar
2014-11-10 14:59 ` [PATCH v4 2/2] ARM: dts: keystone: add generic pm controller node Grygorii Strashko
2014-11-10 15:13 ` [PATCH v4 0/2] ARM: keystone: pm: switch to use generic pm domains Grygorii Strashko
[not found] ` <5460D601.70504-l0cyMroinI0@public.gmane.org>
2014-11-10 18:51 ` santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hsihcmjwu.fsf@deeprootsystems.com \
--to=khilman-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).