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

[Paul Walmsley]

Hi Santosh

On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:

> On Thu, Feb 2, 2012 at 3:47 PM, Shilimkar, Santosh
> <santosh.shilimkar at ti.com> wrote:
> > On Thu, Feb 2, 2012 at 3:35 PM, Paul Walmsley <paul at pwsan.com> wrote:
> >> On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:
> >>
> >>> 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