From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs
Date: Thu, 27 Aug 2015 17:24:13 -0700 [thread overview]
Message-ID: <7hmvxc45w2.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAKdAkRS=9Dq+YpMNSjpij0Am4ZD6uUURv74OLLYf+akD=W885A@mail.gmail.com> (Dmitry Torokhov's message of "Tue, 25 Aug 2015 16:47:58 -0700")
Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> On Tue, Aug 25, 2015 at 3:45 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> Doug Anderson <dianders@chromium.org> writes:
>>
>>> To put things in a
>>> concrete way, for pd_vio we'd go through the entire device tree
>>> ourselves and find all properties that look like "power-domains =
>>> <&power RK3288_PD_VIO>;". We'd then find the parent of those
>>> properties and look for a property named "clocks". We'd then iterate
>>> over all those clocks and turn those on. Did I get that right?
>>
>> ... but you make it sound like more work than it is. The genpd already
>> keeps a list of devices that refer to the power domain. In fact, the
>> genpd 'attach' method can be platform-specific, so could be used to keep
>> track of a list (or a subset) of clocks which are needed for reset.
>
> That is not really workable: the attach and detach happen in
> probe/remove path; if you do not have driver for the device you will
> miss the clocks for it.
And in my proposal, I suggested that clocks without drivers are
good candidates to list in the domain, with the caveat that the be
called out (documented) as being device clocks that are missing a
driver, so when a driver shows up they can be moved accordingly, and in
a way that actually describes the hardware.
> And the quirk of this SoC is that we need to
> turn all clocks during domain transition, regardless of whether there
> is a driver for all devices.
I understand. And that "quirk" is not unique to rockchip socs.
Kevin
next prev parent reply other threads:[~2015-08-28 0:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 7:24 [RESEND PATCH v16 0/4] ARM: rk3288: Add PM Domain support Caesar Wang
2015-08-25 7:24 ` [RESEND PATCH v16 1/4] dt-bindings: add document of Rockchip power domain Caesar Wang
2015-08-25 7:24 ` [RESEND PATCH v16 2/4] ARM: power-domain: rockchip: add all the domain type on RK3288 SoCs Caesar Wang
2015-08-25 7:24 ` [RESEND PATCH v16 3/4] soc: rockchip: power-domain: Add power domain driver Caesar Wang
2015-08-25 20:57 ` Kevin Hilman
2015-08-26 9:27 ` Caesar Wang
2015-08-25 7:24 ` [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs Caesar Wang
2015-08-25 21:07 ` Kevin Hilman
2015-08-25 21:48 ` Doug Anderson
2015-08-25 22:45 ` Kevin Hilman
2015-08-25 23:47 ` Dmitry Torokhov
2015-08-28 0:24 ` Kevin Hilman [this message]
2015-08-28 2:03 ` Doug Anderson
2015-08-28 20:02 ` Michael Turquette
2015-08-28 21:08 ` Doug Anderson
2015-08-28 22:53 ` Michael Turquette
2015-08-28 21:28 ` Kevin Hilman
2015-08-25 23:55 ` Doug Anderson
2015-08-26 9:24 ` Caesar Wang
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=7hmvxc45w2.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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).