All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Dmitry Torokhov
	<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Doug Anderson"
	<dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	"Caesar Wang" <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	"Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Ulf Hansson"
	<ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"Tomasz Figa"
	<tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-kernel@vger.kernel.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Kumar Gala" <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"Russell King" <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Arnd Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>,
	"Linus Walleij"
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"Ian Campbell"
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"devicetree@vger.kernel.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"jinkun.hong"
	<jinkun.hong-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Subject: Re: [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-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Dmitry Torokhov's message of "Tue, 25 Aug 2015 16:47:58 -0700")

Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Tue, Aug 25, 2015 at 3:45 PM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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




--
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

WARNING: multiple messages have this Message-ID (diff)
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

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Doug Anderson" <dianders@chromium.org>,
	"Caesar Wang" <wxt@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Tomasz Figa" <tomasz.figa@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jinkun.hong" <jinkun.hong@rock-chips.com>
Subject: Re: [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





  parent reply	other threads:[~2015-08-28  0:24 UTC|newest]

Thread overview: 51+ 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 ` Caesar Wang
2015-08-25  7:24 ` Caesar Wang
     [not found] ` <1440487486-6154-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
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     ` Caesar Wang
2015-08-25  7:24     ` 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     ` Caesar Wang
2015-08-25  7:24     ` 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  7:24     ` Caesar Wang
2015-08-25  7:24     ` Caesar Wang
     [not found]     ` <1440487486-6154-4-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-08-25 20:57       ` Kevin Hilman
2015-08-25 20:57         ` Kevin Hilman
2015-08-25 20:57         ` Kevin Hilman
2015-08-26  9:27         ` Caesar Wang
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  7:24     ` Caesar Wang
2015-08-25  7:24     ` Caesar Wang
2015-08-25 21:07     ` Kevin Hilman
2015-08-25 21:07       ` Kevin Hilman
     [not found]       ` <7hfv37axhj.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2015-08-25 21:48         ` Doug Anderson
2015-08-25 21:48           ` Doug Anderson
2015-08-25 21:48           ` Doug Anderson
     [not found]           ` <CAD=FV=V6oG+9U=W_JZmqCuNo-9-5wW8ffZzG7ZE_3cnSTNAjFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-25 22:45             ` Kevin Hilman
2015-08-25 22:45               ` Kevin Hilman
2015-08-25 22:45               ` Kevin Hilman
     [not found]               ` <7htwrn6l7g.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2015-08-25 23:47                 ` Dmitry Torokhov
2015-08-25 23:47                   ` Dmitry Torokhov
2015-08-25 23:47                   ` Dmitry Torokhov
     [not found]                   ` <CAKdAkRS=9Dq+YpMNSjpij0Am4ZD6uUURv74OLLYf+akD=W885A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-28  0:24                     ` Kevin Hilman [this message]
2015-08-28  0:24                       ` Kevin Hilman
2015-08-28  0:24                       ` Kevin Hilman
2015-08-28  2:03                       ` Doug Anderson
2015-08-28  2:03                         ` Doug Anderson
     [not found]                         ` <CAD=FV=VTR-PBcXXX1jHNw65x_cMP9CKwVWBs+XCcFqFPp7msjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-28 20:02                           ` Michael Turquette
2015-08-28 20:02                             ` Michael Turquette
2015-08-28 20:02                             ` Michael Turquette
2015-08-28 21:08                             ` Doug Anderson
2015-08-28 21:08                               ` Doug Anderson
     [not found]                               ` <CAD=FV=UrWauwX143MSZpus=L7N__jL1dU-FwaE8BU7wi=Lu2Qg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-28 22:53                                 ` Michael Turquette
2015-08-28 22:53                                   ` Michael Turquette
2015-08-28 22:53                                   ` Michael Turquette
2015-08-28 21:28                             ` Kevin Hilman
2015-08-28 21:28                               ` Kevin Hilman
2015-08-25 23:55                 ` Doug Anderson
2015-08-25 23:55                   ` Doug Anderson
2015-08-25 23:55                   ` Doug Anderson
2015-08-26  9:24               ` Caesar Wang
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-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
    --cc=jinkun.hong-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=wxt-TNX95d0MmH7DzftRWevZcw@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 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.