Thread (9 messages) flat view 9 messages, 3 authors, 2012-02-02
DORMANTno replies

[PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()

From: paul@pwsan.com (Paul Walmsley)
Date: 2012-02-02 19:59:25
Also in: linux-omap

Hi Santosh

On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:
On Thu, Feb 2, 2012 at 3:47 PM, Shilimkar, Santosh
[off-list ref] wrote:
quoted
On Thu, Feb 2, 2012 at 3:35 PM, Paul Walmsley [off-list ref] wrote:
quoted
On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:
quoted
Yes, we do have issue with below APIs for OMAP4 and onwards design
because of the PRCM change.

pwrdm_clear_all_prev_pwrst
pwrdm_*_mem_*

There use to be a single power state and memory state register till OMAP3
at power domain level which can give you the logic and memory last test
which is needed for OSWR.

On OMAP4, we have registers per modules and it becomes difficult to model
this difference in APIs. Initially we tried to fix that with [1] and
then later realized
that's not going to work on OMAP4 + devices because of mentioned issue.
If the registers are per-module, it seems like the best place for those
would be the hwmod layer. ?Do you think that makes sense? ?So, something
like omap_hwmod_clear_all_prev_pwrst(), etc.? ?Seems like that should be
pretty efficient.
But all these are power domain registers after all. Rajendra did one version of
" pwrdm_clear_all_prev_pwrst" ?API and inside used hwmod. But then there he
has iterate over all the modules belongs to that power domain.

And if you use hwmod or omap_device kind of API, then ?you need to
build those devices in init or some where.

All of that was not looking so elegant and hence the other path was chosen.
The mess is, the registers are still part of power domains though they
are specific
to module. And Fundamentally power domain is stil the central entity
decides the fate of all the modules within that PD, in terms of context
loss/ret etc.
I looked at the MPUSS file. There are 3 functions which access
power domain registers directly.

- mpuss_clear_prev_logic_pwrst
- cpu_clear_prev_logic_pwrst
- omap4_mpuss_read_prev_context_state

All of these functions access the context registers which
we don't have support today at power domian APIs for
mentioned issue. This file is using power domain APIs
in all possible scenario's except the OSWR scenario
which needs the context register accesses.

if the context clear and read can be handled part of
PD APIs, then we can certainly kill this functions.
That sounds great.  Maybe we can add powerdomain functions for these 
purposes that take both a powerdomain pointer and a hwmod pointer.  That 
should hopefully work.


- Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help