"Basak, Partha" <p-basak2@xxxxxx> writes: [...] >> >> >> >> Why is this better than passing the next power state? >> > >> > This would keep the GPIO function omap2_gpio_prepare_for_idle agnostic >> of Power state definition dependencies. >> > >> >> And why is this better? >> >> Personally, I think the GPIO code should be told about the powerdomain >> state so it can make it's own decision about whether or not to save >> context. >> > > I see your point. > > But, in the approach we have followed so far, we are trying to > localize all Power domain related logic and information in > pm_34xxx.c. If we refer to all other such functions like > omap_uart_prepare_idle(),omap3_intc_prepare_idle(), > musb_context_save_restore()(newly introduced by USB patches for > HWMOD), they are all following the same paradigm. None of these > functions receive the Power state information as a parameter. The idea > is to segregate the Power domain related information into the power > layer. > > In omap2_gpio_prepare_for_idle() implementation, we are just being > consistent with this approach. > Yes, you're following the existing approach, but the existing approach is wrong, so I'm suggesting you change. There was no common design for any of these, and they all behave slightly differently. For example, we should be passing the power state in the UART hook so the UART code doesn't have to check 'enable_off_mode' to know whether or not to save context. IOW, instead of keeping the decision making centralized in the PM core, we should just be notifiying the drivers about the state change. The idle loop is kept simple, and all the inteligence should be in the drivers. Also, the PM core should no be telling a module to save context. It should be notifying the module of a state change. IOW, instead of calling these functions save/restore context, they should be called prepare/resume idle. In the linux-pm community, there are increasing discussions on how to combine CPUidle and runtime PM. So in the medium term, we'll probably be coming up with a more standard way for the idle path to notify drivers using runtime PM. Until that happens, all these prepare/resume idle hooks are just temporary. Kevin -- 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
