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