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@xxxxxxxxxxxxxx> wrote: >> Hi Santosh, >> >> On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar >> <santosh.shilimkar@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
