[PATCH 06/10] omap2+: Remove gptimer_wakeup for now
tony at atomide.com
Mon Jun 27 14:16:16 EDT 2011
* Kevin Hilman <khilman at ti.com> [110627 09:25]:
> Tony Lindgren <tony at atomide.com> writes:
> > * Santosh Shilimkar <santosh.shilimkar at ti.com> [110623 08:09]:
> >> On 6/23/2011 8:35 PM, Kevin Hilman wrote:
> >> >Tony Lindgren<tony at atomide.com> writes:
> >> >
> >> >So now, the only thing OMAP-specific is the debugfs file used to trigger
> >> >it.
> >> >
> >> >>Maybe Kevin can just carry it along in the PM branch for now?
> >> >
> >> >I'd prefer to keep it in mainline as this is a very important feature
> >> >for the PM functionality already in mainline.
> >> >
> >> I agree with Kevin and that's what have been saying from begining when
> >> we decided to drop this feature. The new patch from Kevin is already
> >> doing this in more generic way than that was before.
> > To me Kevin's later patch makes more sense, but still has few issues:
> > - It keeps the dependency between PM debug code and sys_timer code.
> > That's yet another artificial blocker for making PM code a loadable
> > module. We really don't want to export anything from the sys_timer code.
> > - The interface for programming a wake-up timer should be Linux generic,
> > not omap specific.
> > Further, it's a CONFIG_PM_DEBUG patch. So that code should not be
> > in the mainline kernel.
> Please clarify why PM debug code shouldn't be in mainline?
Oh sorry I did not mean that. I meant that it's a debug interface so it's
not like we should freeze it. My main issues are the dependencies and
the interface above.
Anyways, I guess you are using this to test suspend on a remote system
with no hardware trigger to wake it back up?
If so, how about some RTC alarm like interface to set the wake-up
event after suspending? There may be a way to do this already and
have it triggered from rtc-omap..
More information about the linux-arm-kernel