On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote:
"Bedia, Vaibhav" [off-list ref] writes:
Hi Kevin.
quoted
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