On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote: > "Bedia, Vaibhav" <vaibhav.bedia@xxxxxx> writes: Hi Kevin. > > If it does, perhaps there should some other mechanism for letting > > users control the system behavior. > > Come to think of it, the right solution here is probably to use runtime > PM. We could then to add some custom hooks for davinci_emac in the > device code to use enable_hlt/disable_hlt based on activity. That was my first thought, actually, but that only works if its okay for the driver to call enable_hlt/disable_hlt directly (i.e., have runtime_suspend() call enable_hlt() and runtime_resume() call disable_hlt()). However, I assumed it would _not_ be acceptable for the driver to issue those calls directly. Its a platform-specific issue that we shouldn't be polluting the driver with and there are currently no drivers that call them under the drivers directory. If its not okay to call enable_hlt/disable_hlt directly, then we still need callback hooks to the plaform code (i.e., some version of this patch). > In order to do that though, the davinci_emac driver needs to be runtime > PM converted. We probably should pm_runtime-ize the driver either way but we need to resolve the question of whether its okay for the driver to call enable_hlt/disable_hlt directly or not. If it is okay, we call them in runtime_suspend/resume. If it isn't okay, then we still need platform callback hooks. Mark -- 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
