All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Caesar Wang <caesar.wang@rock-chips.com>,
	linus.walleij@linaro.org, linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-doc@vger.kernel.org, dianders@chromium.org,
	linux-rockchip@lists.infradead.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	fzf@rock-chips.com, cf@rock-chips.com,
	Jack Dai <jack.dai@rock-chips.com>,
	"jinkun.hong" <jinkun.hong@rock-chips.com>
Subject: Re: [PATCH v10 2/3] power-domain: rockchip: add power doamin driver
Date: Thu, 13 Nov 2014 12:24:47 -0800	[thread overview]
Message-ID: <7hh9y2c0hc.fsf@deeprootsystems.com> (raw)
In-Reply-To: <11419951.x8p1Z4vKjh@diego> ("Heiko =?utf-8?Q?St=C3=BCbner=22?= =?utf-8?Q?'s?= message of "Wed, 12 Nov 2014 01:10:28 +0100")

Heiko Stübner <heiko@sntech.de> writes:

> Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
>> Caesar Wang <caesar.wang@rock-chips.com> writes:
>> > In order to meet high performance and low power requirements, a power
>> > management unit is designed or saving power when RK3288 in low power mode.
>> > The RK3288 PMU is dedicated for managing the power ot the whole chip.
>> > 
>> > Signed-off-by: Jack Dai <jack.dai@rock-chips.com>
>> > Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
>> > Signed-off-by: Caesar Wang <caesar.wang@rock-chips.com>
>> > 
>> > ---
>> > 
>> > Changes in v10:
>> >     - this switches over domain infos to use masks instead of recomputing
>> >     
>> >       them each time and also gets rid of custom domain translator and
>> >       uses standard onecell on.
>> > 
>> > Changes in v9:
>> >     - fix v8 changes as follows:
>> >     - This reconciles the v2 and v7 code so that we power domain have
>> >     
>> >       lists of clocks they toggle on and off during power transitions and
>> >       independently from power domains clocks we attach clocks to devices
>> >       comprising power domain and prepare them so they are turn on and off
>> >       by runtime PM.
>> 
>> I still don't like having lists of clocks in the power-domain DT.
>> 
>> DT is supposed to describe the hardware, and clocks are properties of
>> devices, not power-domains, so the DT description should follow from that.
>
> on the policy side one could argue that if the clock needs to be enabled to 
> achieve sucessful domain state-changes, that it is also a property of the 
> domain itself in addition to the device.

You could, but from a hardware perspective, the clock is a property of
the device.

> And on the pratical side we don't have drivers nor bindings for a big part of 
> the domain users - and this will probably be true for quite some time. This of 
> course makes it very impractical (or impossible) to collect the clocks for 
> parts like the gpu (mali), hevc, vcodec (video encoder/decoder), rga (2d 
> stuff), iep, isp.

This doesn't sound impossible at all.

You have to collect the clocks anyways.  The only debate is whether to
list them in the device node or the power-domain node.  

Even for devices without drivers, you just need a minimal node in the DT if
which lists the clocks and has a phandle to the parent power domain.

Sounds rather simple to me, and since the DT is supposed to describe the
hardware, doing it this way makes looking at the DT actually help
understand the hardware.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v10 2/3] power-domain: rockchip: add power doamin driver
Date: Thu, 13 Nov 2014 12:24:47 -0800	[thread overview]
Message-ID: <7hh9y2c0hc.fsf@deeprootsystems.com> (raw)
In-Reply-To: <11419951.x8p1Z4vKjh@diego> ("Heiko =?utf-8?Q?St=C3=BCbner=22?= =?utf-8?Q?'s?= message of "Wed, 12 Nov 2014 01:10:28 +0100")

Heiko St?bner <heiko@sntech.de> writes:

> Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
>> Caesar Wang <caesar.wang@rock-chips.com> writes:
>> > In order to meet high performance and low power requirements, a power
>> > management unit is designed or saving power when RK3288 in low power mode.
>> > The RK3288 PMU is dedicated for managing the power ot the whole chip.
>> > 
>> > Signed-off-by: Jack Dai <jack.dai@rock-chips.com>
>> > Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
>> > Signed-off-by: Caesar Wang <caesar.wang@rock-chips.com>
>> > 
>> > ---
>> > 
>> > Changes in v10:
>> >     - this switches over domain infos to use masks instead of recomputing
>> >     
>> >       them each time and also gets rid of custom domain translator and
>> >       uses standard onecell on.
>> > 
>> > Changes in v9:
>> >     - fix v8 changes as follows:
>> >     - This reconciles the v2 and v7 code so that we power domain have
>> >     
>> >       lists of clocks they toggle on and off during power transitions and
>> >       independently from power domains clocks we attach clocks to devices
>> >       comprising power domain and prepare them so they are turn on and off
>> >       by runtime PM.
>> 
>> I still don't like having lists of clocks in the power-domain DT.
>> 
>> DT is supposed to describe the hardware, and clocks are properties of
>> devices, not power-domains, so the DT description should follow from that.
>
> on the policy side one could argue that if the clock needs to be enabled to 
> achieve sucessful domain state-changes, that it is also a property of the 
> domain itself in addition to the device.

You could, but from a hardware perspective, the clock is a property of
the device.

> And on the pratical side we don't have drivers nor bindings for a big part of 
> the domain users - and this will probably be true for quite some time. This of 
> course makes it very impractical (or impossible) to collect the clocks for 
> parts like the gpu (mali), hevc, vcodec (video encoder/decoder), rga (2d 
> stuff), iep, isp.

This doesn't sound impossible at all.

You have to collect the clocks anyways.  The only debate is whether to
list them in the device node or the power-domain node.  

Even for devices without drivers, you just need a minimal node in the DT if
which lists the clocks and has a phandle to the parent power domain.

Sounds rather simple to me, and since the DT is supposed to describe the
hardware, doing it this way makes looking at the DT actually help
understand the hardware.

Kevin

  reply	other threads:[~2014-11-13 20:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-11  7:19 [PATCH v10 0/3] ARM: rk3288: Add PM Domain support Caesar Wang
2014-11-11  7:19 ` Caesar Wang
2014-11-11  7:19 ` [PATCH v10 1/3] dt-bindings: add document of Rockchip power domain Caesar Wang
2014-11-11  7:19   ` Caesar Wang
2014-11-11  7:19 ` [PATCH v10 2/3] power-domain: rockchip: add power doamin driver Caesar Wang
2014-11-11  7:19   ` Caesar Wang
2014-11-11 16:53   ` Kevin Hilman
2014-11-11 16:53     ` Kevin Hilman
2014-11-12  0:10     ` Heiko Stübner
2014-11-12  0:10       ` Heiko Stübner
2014-11-13 20:24       ` Kevin Hilman [this message]
2014-11-13 20:24         ` Kevin Hilman
2014-11-12 19:22   ` Doug Anderson
2014-11-12 19:22     ` Doug Anderson
2014-11-12 19:22     ` Doug Anderson
2014-11-11  7:19 ` [PATCH v10 3/3] ARM: dts: add rk3288 power-domain node Caesar Wang
2014-11-11  7:19   ` 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=7hh9y2c0hc.fsf@deeprootsystems.com \
    --to=khilman@kernel.org \
    --cc=caesar.wang@rock-chips.com \
    --cc=cf@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fzf@rock-chips.com \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=heiko@sntech.de \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jack.dai@rock-chips.com \
    --cc=jinkun.hong@rock-chips.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@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.