From: Kevin Hilman <khilman@linaro.org>
To: Rajendra Nayak <rnayak@ti.com>
Cc: paul@pwsan.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm
Date: Fri, 14 Jun 2013 06:59:45 -0700 [thread overview]
Message-ID: <878v2caj3i.fsf@linaro.org> (raw)
In-Reply-To: <1371118124-15910-2-git-send-email-rnayak@ti.com> (Rajendra Nayak's message of "Thu, 13 Jun 2013 15:38:43 +0530")
Rajendra Nayak <rnayak@ti.com> writes:
> The powerdomain framework expects all powerdomains to be associated with
s/expects/currently expects/
> a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
> family, or for the upcoming AM437x and DRA7 SoCs') which
> do not have a Voltage controller/Voltage Processor (neither the SR I2C
> bus to communicate with the PMIC) there is no need for a Powerdomain to have
> a voltage domain association (since they are really non scaleable, even
> though the voltage domains exist in place).
This last phrase inside the parentheses doesn't make sense to me.
Reading that makes me think that the lack of an on-chip voltage domain
means that evn an external regulators can't scale the voltage, which I
don't believe is the case.
> Extend the arch operations to add an api which the powerdomain core can
> then use to identify if a voltdm lookup and association for a powerdomain
> is really needed.
Yes, this idea looks right to me.
In addition to the wording above, a minor nit below...
[...]
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index 140c360..8ed89de 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -166,6 +166,7 @@ struct powerdomain {
> * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
> * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep sleep
> * @pwrdm_wait_transition: Wait for a pd state transition to complete
> + * @pwrdm_has_voltdmi: Check if a voltdm association is needed
s/voltdmi/voltdm/
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@linaro.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm
Date: Fri, 14 Jun 2013 06:59:45 -0700 [thread overview]
Message-ID: <878v2caj3i.fsf@linaro.org> (raw)
In-Reply-To: <1371118124-15910-2-git-send-email-rnayak@ti.com> (Rajendra Nayak's message of "Thu, 13 Jun 2013 15:38:43 +0530")
Rajendra Nayak <rnayak@ti.com> writes:
> The powerdomain framework expects all powerdomains to be associated with
s/expects/currently expects/
> a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
> family, or for the upcoming AM437x and DRA7 SoCs') which
> do not have a Voltage controller/Voltage Processor (neither the SR I2C
> bus to communicate with the PMIC) there is no need for a Powerdomain to have
> a voltage domain association (since they are really non scaleable, even
> though the voltage domains exist in place).
This last phrase inside the parentheses doesn't make sense to me.
Reading that makes me think that the lack of an on-chip voltage domain
means that evn an external regulators can't scale the voltage, which I
don't believe is the case.
> Extend the arch operations to add an api which the powerdomain core can
> then use to identify if a voltdm lookup and association for a powerdomain
> is really needed.
Yes, this idea looks right to me.
In addition to the wording above, a minor nit below...
[...]
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index 140c360..8ed89de 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -166,6 +166,7 @@ struct powerdomain {
> * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
> * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep sleep
> * @pwrdm_wait_transition: Wait for a pd state transition to complete
> + * @pwrdm_has_voltdmi: Check if a voltdm association is needed
s/voltdmi/voltdm/
Kevin
next prev parent reply other threads:[~2013-06-14 13:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 10:08 [PATCH 0/2] Remove unused voltagedomain data for AM33xx Rajendra Nayak
2013-06-13 10:08 ` Rajendra Nayak
2013-06-13 10:08 ` [PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm Rajendra Nayak
2013-06-13 10:08 ` Rajendra Nayak
2013-06-14 13:59 ` Kevin Hilman [this message]
2013-06-14 13:59 ` Kevin Hilman
2013-06-13 10:08 ` [PATCH 2/2] ARM: AM33xx: Remove the unused voltagedomain data Rajendra Nayak
2013-06-13 10:08 ` Rajendra Nayak
2013-06-14 2:46 ` [PATCH 0/2] Remove unused voltagedomain data for AM33xx Paul Walmsley
2013-06-14 2:46 ` Paul Walmsley
2013-06-14 13:14 ` Nishanth Menon
2013-06-14 13:14 ` Nishanth Menon
2013-06-14 14:01 ` Kevin Hilman
2013-06-14 14:01 ` Kevin Hilman
2013-06-17 5:08 ` Hiremath, Vaibhav
2013-06-17 5:08 ` Hiremath, Vaibhav
2013-06-17 5:12 ` Rajendra Nayak
2013-06-17 5:12 ` Rajendra Nayak
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=878v2caj3i.fsf@linaro.org \
--to=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.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.