All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Jean Pihet <jean.pihet@newoldbits.com>, Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, b-cousson@ti.com, khilman@ti.com,
	linux-arm-kernel@lists.infradead.org, Jean Pihet <j-pihet@ti.com>
Subject: Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states
Date: Wed, 23 May 2012 12:09:30 +0530	[thread overview]
Message-ID: <4FBC8622.3020308@ti.com> (raw)
In-Reply-To: <CAMQu2gwBYUmBLV+wByVxto_ETu6-YjHycGWnhVn-Tb9pJUngDw@mail.gmail.com>

Jean,

On Monday 21 May 2012 07:55 PM, Shilimkar, Santosh wrote:
> Jean,
> 
> On Mon, May 21, 2012 at 7:23 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>> Hi Santosh,
>>
>> On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:

[...]

>> What do you think?
>>
> I like the idea as mentioned. I just think the series should already
> take care of memory state, logic state and quirk flags to see how
> it looks overall. Will have one more fresh look at the series but if
> you have subsequent WIP patches which can handle the other
> parameters, please send that link.
> 
I have scanned the series again. Somehow I still find myself
not convinced with the approach. I found having PD OSWR
CSWR state is the only change from this series helps to
some extent. But if you look from PRCM point of view,
they are already two distinct power domain states. Only
bad part from programming perspective, is, it's needs
to take care of additional bit to set and get PD state.

If we actually support 'PWRDM_POWER_OSWRET" and
'PWRDM_POWER_CSWRET" as valid state then we can do
everything without the functional power state series.
I mean we can use 'omap_set_pwrdm_state()' as a single
API for programming the PD, instead of duplicating
these all over the place.

OSWR by definition can be customised per power
domain based on various supported logic and
memory states.With this series, OSWR definition
also become static and if that is agreed then
we should cab just make that as a state like
ON/OFF/INACTIVE.

But I don't want to object this series if
Paul is convinced and agrees with the approach.
My view may be bit narrow but I am not convinced
with the approach.

Btw, ther are some real differences in PD INACTIVE state
in OMAP3 and OMAP4+ devices. I had some discussion with
Paul before on it. It needs to be clubbed with
voltagedomain layer to properly represent. Some
discussion was on the list [1] and some of that
was off list with hardware designers. Relevant
thread is here [1]

Regards
Santosh

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041133.html

WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states
Date: Wed, 23 May 2012 12:09:30 +0530	[thread overview]
Message-ID: <4FBC8622.3020308@ti.com> (raw)
In-Reply-To: <CAMQu2gwBYUmBLV+wByVxto_ETu6-YjHycGWnhVn-Tb9pJUngDw@mail.gmail.com>

Jean,

On Monday 21 May 2012 07:55 PM, Shilimkar, Santosh wrote:
> Jean,
> 
> On Mon, May 21, 2012 at 7:23 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>> Hi Santosh,
>>
>> On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:

[...]

>> What do you think?
>>
> I like the idea as mentioned. I just think the series should already
> take care of memory state, logic state and quirk flags to see how
> it looks overall. Will have one more fresh look at the series but if
> you have subsequent WIP patches which can handle the other
> parameters, please send that link.
> 
I have scanned the series again. Somehow I still find myself
not convinced with the approach. I found having PD OSWR
CSWR state is the only change from this series helps to
some extent. But if you look from PRCM point of view,
they are already two distinct power domain states. Only
bad part from programming perspective, is, it's needs
to take care of additional bit to set and get PD state.

If we actually support 'PWRDM_POWER_OSWRET" and
'PWRDM_POWER_CSWRET" as valid state then we can do
everything without the functional power state series.
I mean we can use 'omap_set_pwrdm_state()' as a single
API for programming the PD, instead of duplicating
these all over the place.

OSWR by definition can be customised per power
domain based on various supported logic and
memory states.With this series, OSWR definition
also become static and if that is agreed then
we should cab just make that as a state like
ON/OFF/INACTIVE.

But I don't want to object this series if
Paul is convinced and agrees with the approach.
My view may be bit narrow but I am not convinced
with the approach.

Btw, ther are some real differences in PD INACTIVE state
in OMAP3 and OMAP4+ devices. I had some discussion with
Paul before on it. It needs to be clubbed with
voltagedomain layer to properly represent. Some
discussion was on the list [1] and some of that
was off list with hardware designers. Relevant
thread is here [1]

Regards
Santosh

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041133.html

  reply	other threads:[~2012-05-23  6:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 12:39 [PATCH v3 0/6] ARM: OMAP2+: PM: introduce the power domains functional states jean.pihet
2012-04-18 12:39 ` jean.pihet at newoldbits.com
2012-04-18 12:39 ` [PATCH 1/6] ARM: OMAP2+: PM: protect the power domain state change by a mutex jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
2012-05-07  6:41   ` Paul Walmsley
2012-05-07  6:41     ` Paul Walmsley
2012-05-08  8:28     ` Jean Pihet
2012-05-08  8:28       ` Jean Pihet
2012-04-18 12:39 ` [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
2012-05-07  9:28   ` Paul Walmsley
2012-05-07  9:28     ` Paul Walmsley
2012-05-08  8:40     ` Jean Pihet
2012-05-08  8:40       ` Jean Pihet
2012-05-17 10:04       ` Santosh Shilimkar
2012-05-17 10:04         ` Santosh Shilimkar
2012-05-21 13:53         ` Jean Pihet
2012-05-21 13:53           ` Jean Pihet
2012-05-21 14:25           ` Shilimkar, Santosh
2012-05-21 14:25             ` Shilimkar, Santosh
2012-05-23  6:39             ` Santosh Shilimkar [this message]
2012-05-23  6:39               ` Santosh Shilimkar
2012-04-18 12:39 ` [PATCH 3/6] ARM: OMAP2+: PM: use the functional power states API jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
2012-04-18 12:39 ` [PATCH 4/6] ARM: OMAP2+: PM: introduce power domains logic and memory functional states jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
2012-04-18 12:39 ` [PATCH 5/6] ARM: OMAP2+: PM: use the functional power states API for logic and memory jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
2012-04-18 12:39 ` [PATCH 6/6] ARM: OMAP2+: PM: use power domain functional state in stats counters jean.pihet
2012-04-18 12:39   ` jean.pihet at newoldbits.com
  -- strict thread matches above, loose matches on Subject: below --
2012-04-11 20:46 [RFC/PATCH v2 0/6] ARM: OMAP2+: PM: introduce the power domains functional states jean.pihet
2012-04-11 20:46 ` [PATCH 2/6] ARM: OMAP2+: PM: introduce " jean.pihet

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=4FBC8622.3020308@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=b-cousson@ti.com \
    --cc=j-pihet@ti.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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.