From: Doug Anderson <dianders@chromium.org>
To: Kevin Hilman <khilman@kernel.org>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"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 19:03:20 -0700 [thread overview]
Message-ID: <CAD=FV=VTR-PBcXXX1jHNw65x_cMP9CKwVWBs+XCcFqFPp7msjA@mail.gmail.com> (raw)
In-Reply-To: <7hmvxc45w2.fsf@deeprootsystems.com>
Kevin,
On Thu, Aug 27, 2015 at 5:24 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> 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.
What happens if someone disables the driver using the CONFIG subsystem?
What happens if this is a device that someone has set to 'status =
"disabled";' in the device tree?
Even if the device is disabled in one of those two ways, we still need
the clocks to be turned on. ...so if we turn on/off the VIO domain we
need to turn on the EDP clock even if there's no EDP in the current
board / config. We might turn on/off VIO for one of the other devices
in the VIO domain for one of the other devices in VIO that we are
using.
-Doug
WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
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 19:03:20 -0700 [thread overview]
Message-ID: <CAD=FV=VTR-PBcXXX1jHNw65x_cMP9CKwVWBs+XCcFqFPp7msjA@mail.gmail.com> (raw)
In-Reply-To: <7hmvxc45w2.fsf@deeprootsystems.com>
Kevin,
On Thu, Aug 27, 2015 at 5:24 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> 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.
What happens if someone disables the driver using the CONFIG subsystem?
What happens if this is a device that someone has set to 'status =
"disabled";' in the device tree?
Even if the device is disabled in one of those two ways, we still need
the clocks to be turned on. ...so if we turn on/off the VIO domain we
need to turn on the EDP clock even if there's no EDP in the current
board / config. We might turn on/off VIO for one of the other devices
in the VIO domain for one of the other devices in VIO that we are
using.
-Doug
next prev parent reply other threads:[~2015-08-28 2:03 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
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
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
2015-08-25 21:48 ` Doug Anderson
2015-08-25 21:48 ` Doug Anderson
2015-08-25 21:48 ` Doug Anderson
2015-08-25 22:45 ` Kevin Hilman
2015-08-25 22:45 ` Kevin Hilman
2015-08-25 22:45 ` Kevin Hilman
2015-08-25 23:47 ` Dmitry Torokhov
2015-08-25 23:47 ` Dmitry Torokhov
2015-08-25 23:47 ` Dmitry Torokhov
2015-08-28 0:24 ` Kevin Hilman
2015-08-28 0:24 ` Kevin Hilman
2015-08-28 0:24 ` Kevin Hilman
2015-08-28 2:03 ` Doug Anderson [this message]
2015-08-28 2:03 ` Doug Anderson
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
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='CAD=FV=VTR-PBcXXX1jHNw65x_cMP9CKwVWBs+XCcFqFPp7msjA@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=galak@codeaurora.org \
--cc=heiko@sntech.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jinkun.hong@rock-chips.com \
--cc=khilman@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=robh+dt@kernel.org \
--cc=tomasz.figa@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=wxt@rock-chips.com \
/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.