From: Kevin Hilman <khilman@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>,
ssantosh@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
grant.likely@secretlab.ca, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Ulf Hansson <ulf.hansson@linaro.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains
Date: Mon, 17 Nov 2014 13:50:13 -0800 [thread overview]
Message-ID: <7hsihhzecq.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1618855.DXsjWXLqau@wuerfel> (Arnd Bergmann's message of "Mon, 17 Nov 2014 21:37:37 +0100")
Arnd Bergmann <arnd@arndb.de> writes:
> On Monday 17 November 2014 11:14:16 Kevin Hilman wrote:
>> >>
>> >> So, The Keystone 2 Generic PM Controller is just a proxy PM layer here between
>> >> device and Generic clock manipulation PM callbacks.
>> >> It fills per-device clock list when device is attached to GPD and
>> >> ensures that all clocks from that list enabled/disabled when device is
>> >> started/stopped.
>> >
>> > The idea of such a generic power domain implementation sounds useful, but
>> > it has absolutely no business in platform specific code.
>>
>> Yes it does. This isn't a generic power domain implementation, but
>> rather just the platform-specific glue that hooks up the clocks to the
>> right devices and power-domains so that the generic power-domain and
>> generic pm_clocks code does the right thing.
>
> How would you do this on an arm64 version of keystone then? With
> the current approach, you'd need to add a machine specific directory,
> and that seems completely pointless since this is not even about
> a hardware requirement.
Yeah, you're right. I misunderstood you're original comment.
>> > I suggest you either remove the power domain proxy from your drivers
>> > and use the clocks directly,
>>
>> No. That's a step in the wrong direction. This change isn't affecting
>> drivers directly. It's the runtime PM and generic power domain layers
>> that handle this, and runtime PM adapted drivers don't need any changes.
>>
>> > or come up with an implementation that can be used across other
>> > platforms and CPU architectures.
>>
>> We already have those in the generic power domain and the pm_clock
>> layers. This series is just hooking those up for Keystone.
>
> Then why not add the missing piece to the generic power domain
> code to avoid having to add infrastructure to the platform
> for it?
Yes, good point. There is nothing keystone-specific in this glue.
Grygorii, what about adding a feature to the generic domain parsing so
that it can get clocks from device nodes that are part of the domain,
and so it sets up pm_clk accordingly.
I've recently seen other SoCs doing very similar, so this really should
be generalized.
I've been looking at this primarily as a right incremental improvement
from what is there for Keystone today, but Arnd is right. This should
be moved out of platform code.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains
Date: Mon, 17 Nov 2014 13:50:13 -0800 [thread overview]
Message-ID: <7hsihhzecq.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1618855.DXsjWXLqau@wuerfel> (Arnd Bergmann's message of "Mon, 17 Nov 2014 21:37:37 +0100")
Arnd Bergmann <arnd@arndb.de> writes:
> On Monday 17 November 2014 11:14:16 Kevin Hilman wrote:
>> >>
>> >> So, The Keystone 2 Generic PM Controller is just a proxy PM layer here between
>> >> device and Generic clock manipulation PM callbacks.
>> >> It fills per-device clock list when device is attached to GPD and
>> >> ensures that all clocks from that list enabled/disabled when device is
>> >> started/stopped.
>> >
>> > The idea of such a generic power domain implementation sounds useful, but
>> > it has absolutely no business in platform specific code.
>>
>> Yes it does. This isn't a generic power domain implementation, but
>> rather just the platform-specific glue that hooks up the clocks to the
>> right devices and power-domains so that the generic power-domain and
>> generic pm_clocks code does the right thing.
>
> How would you do this on an arm64 version of keystone then? With
> the current approach, you'd need to add a machine specific directory,
> and that seems completely pointless since this is not even about
> a hardware requirement.
Yeah, you're right. I misunderstood you're original comment.
>> > I suggest you either remove the power domain proxy from your drivers
>> > and use the clocks directly,
>>
>> No. That's a step in the wrong direction. This change isn't affecting
>> drivers directly. It's the runtime PM and generic power domain layers
>> that handle this, and runtime PM adapted drivers don't need any changes.
>>
>> > or come up with an implementation that can be used across other
>> > platforms and CPU architectures.
>>
>> We already have those in the generic power domain and the pm_clock
>> layers. This series is just hooking those up for Keystone.
>
> Then why not add the missing piece to the generic power domain
> code to avoid having to add infrastructure to the platform
> for it?
Yes, good point. There is nothing keystone-specific in this glue.
Grygorii, what about adding a feature to the generic domain parsing so
that it can get clocks from device nodes that are part of the domain,
and so it sets up pm_clk accordingly.
I've recently seen other SoCs doing very similar, so this really should
be generalized.
I've been looking at this primarily as a right incremental improvement
from what is there for Keystone today, but Arnd is right. This should
be moved out of platform code.
Kevin
next prev parent reply other threads:[~2014-11-17 21:50 UTC|newest]
Thread overview: 107+ 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 ` Grygorii Strashko
2014-11-10 14:59 ` Grygorii Strashko
2014-11-10 14:59 ` [PATCH v4 1/2] " Grygorii Strashko
2014-11-10 14:59 ` Grygorii Strashko
2014-11-10 14:59 ` Grygorii Strashko
2014-11-10 15:06 ` Arnd Bergmann
2014-11-10 15:06 ` Arnd Bergmann
2014-11-10 17:38 ` Grygorii Strashko
2014-11-10 17:38 ` Grygorii Strashko
2014-11-10 17:38 ` Grygorii Strashko
2014-11-10 20:36 ` Arnd Bergmann
2014-11-10 20:36 ` Arnd Bergmann
2014-11-17 19:14 ` Kevin Hilman
2014-11-17 19:14 ` Kevin Hilman
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 20:37 ` Arnd Bergmann
2014-11-17 20:37 ` Arnd Bergmann
2014-11-17 21:50 ` Kevin Hilman [this message]
2014-11-17 21:50 ` Kevin Hilman
2014-11-18 18:54 ` Grygorii Strashko
2014-11-18 18:54 ` Grygorii Strashko
2014-11-18 18:54 ` Grygorii Strashko
2014-11-18 19:32 ` Arnd Bergmann
2014-11-18 19:32 ` Arnd Bergmann
2014-11-19 11:32 ` Grygorii Strashko
2014-11-19 11:32 ` Grygorii Strashko
2014-11-19 11:32 ` Grygorii Strashko
2014-11-19 13:47 ` Arnd Bergmann
2014-11-19 13:47 ` Arnd Bergmann
2014-11-20 11:34 ` Ulf Hansson
2014-11-20 11:34 ` Ulf Hansson
2014-11-20 12:03 ` Grygorii Strashko
2014-11-20 12:03 ` Grygorii Strashko
2014-11-20 12:03 ` Grygorii Strashko
2014-11-20 13:12 ` Ulf Hansson
2014-11-20 13:12 ` Ulf Hansson
2014-11-20 13:32 ` Geert Uytterhoeven
2014-11-20 13:32 ` Geert Uytterhoeven
2014-11-20 15:32 ` Grygorii Strashko
2014-11-20 15:32 ` Grygorii Strashko
2014-11-20 15:32 ` Grygorii Strashko
2014-11-20 20:22 ` Kevin Hilman
2014-11-20 20:22 ` Kevin Hilman
2014-11-20 20:22 ` Kevin Hilman
2014-11-20 20:26 ` Geert Uytterhoeven
2014-11-20 20:26 ` Geert Uytterhoeven
2014-11-20 21:48 ` Kevin Hilman
2014-11-20 21:48 ` Kevin Hilman
2014-11-20 21:48 ` Kevin Hilman
2014-11-20 21:54 ` Geert Uytterhoeven
2014-11-20 21:54 ` Geert Uytterhoeven
[not found] ` <CAMuHMdVXGPu7x706NxqO3rn3KuRbPbD_ZQsJtDH4Hf31AaRR+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 1:30 ` Kevin Hilman
2014-11-21 1:30 ` Kevin Hilman
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 8:06 ` Geert Uytterhoeven
2014-11-21 8:06 ` Geert Uytterhoeven
2014-11-21 18:58 ` Grygorii Strashko
2014-11-21 18:58 ` Grygorii Strashko
2014-11-21 18:58 ` Grygorii Strashko
[not found] ` <546F8B39.1080106-l0cyMroinI0@public.gmane.org>
2014-11-21 19:29 ` Kevin Hilman
2014-11-21 19:29 ` Kevin Hilman
2014-11-21 19:29 ` Kevin Hilman
2014-11-21 20:14 ` Grygorii Strashko
2014-11-21 20:14 ` Grygorii Strashko
2014-11-21 20:14 ` Grygorii Strashko
2014-11-24 10:50 ` Arnd Bergmann
2014-11-24 10:50 ` Arnd Bergmann
2014-11-25 6:44 ` Mike Turquette
2014-11-25 6:44 ` Mike Turquette
2014-11-25 10:33 ` Arnd Bergmann
2014-11-25 10:33 ` Arnd Bergmann
2014-11-25 11:08 ` Grygorii Strashko
2014-11-25 11:08 ` Grygorii Strashko
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 12:09 ` Arnd Bergmann
2014-11-25 12:09 ` Arnd Bergmann
2014-11-25 13:30 ` Grygorii Strashko
2014-11-25 13:30 ` Grygorii Strashko
2014-11-25 13:30 ` Grygorii Strashko
2014-11-25 14:04 ` Russell King - ARM Linux
2014-11-25 14:04 ` Russell King - ARM Linux
2014-11-25 14:53 ` Grygorii Strashko
2014-11-25 14:53 ` Grygorii Strashko
2014-11-25 14:53 ` Grygorii Strashko
2014-11-25 16:28 ` santosh shilimkar
2014-11-25 16:28 ` santosh shilimkar
[not found] ` <CAMuHMdU6G35SP-P7bt6RJQk59CrGcKE2XM4N3o8Dv3qxZU7gxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 19:20 ` Kevin Hilman
2014-11-21 19:20 ` Kevin Hilman
2014-11-21 19:20 ` Kevin Hilman
[not found] ` <546E0970.5090301-l0cyMroinI0@public.gmane.org>
2014-11-21 9:04 ` Geert Uytterhoeven
2014-11-21 9:04 ` Geert Uytterhoeven
2014-11-21 9:04 ` Geert Uytterhoeven
2014-11-18 2:18 ` santosh.shilimkar
2014-11-18 2:18 ` santosh.shilimkar at oracle.com
2014-11-10 14:59 ` [PATCH v4 2/2] ARM: dts: keystone: add generic pm controller node Grygorii Strashko
2014-11-10 14:59 ` Grygorii Strashko
2014-11-10 14:59 ` Grygorii Strashko
2014-11-10 15:13 ` [PATCH v4 0/2] ARM: keystone: pm: switch to use generic pm domains Grygorii Strashko
2014-11-10 15:13 ` Grygorii Strashko
2014-11-10 15:13 ` Grygorii Strashko
[not found] ` <5460D601.70504-l0cyMroinI0@public.gmane.org>
2014-11-10 18:51 ` santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA
2014-11-10 18:51 ` santosh.shilimkar
2014-11-10 18:51 ` santosh.shilimkar at oracle.com
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=7hsihhzecq.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=geert@linux-m68k.org \
--cc=grant.likely@secretlab.ca \
--cc=grygorii.strashko@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=ssantosh@kernel.org \
--cc=ulf.hansson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.