On Thu, Apr 30, 2009 at 11:21 PM, Kevin Hilman
wrote:
>>> Also, I still think the WKST register reading should be done in the
>>> PRCM interrupt handler. In your previous attempt, you were seeing a
>>> bunch of non-device wakeup related interrupts. Can you try again
>>> with the attached patch
Kyuwon,
Kim Kyuwon writes:
> Hi Kevin,
> Thank you for showing steady interest in this driver.
>
> On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman
> wrote:
>>
>> Hi Kyuwon,
>>
>> While I still like the concept of this driver, I'm still not quite
>> happy about how it is implemented for various re
Hi Kevin,
Thank you for showing steady interest in this driver.
On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman
wrote:
>
> Hi Kyuwon,
>
> While I still like the concept of this driver, I'm still not quite
> happy about how it is implemented for various reasons. Most of which
> have to do with the
Kim Kyuwon writes:
> Sometimes, it is necessary to find out "what does wake up my board
> from suspend?". Notifying wake-up source feature may be used to blame
> unexpected wake-up events which increase power consumption. And user
> mode applications can act smartly according to the wake-up event
Hi Kevin,
Have you had chance to review this new version of wakeup driver? :)
Regards,
Kyuwon
On Fri, Apr 3, 2009 at 7:43 PM, Kim Kyuwon wrote:
> Sometimes, it is necessary to find out "what does wake up my board
> from suspend?". Notifying wake-up source feature may be used to blame
> unexpect
Sometimes, it is necessary to find out "what does wake up my board
from suspend?". Notifying wake-up source feature may be used to blame
unexpected wake-up events which increase power consumption. And user
mode applications can act smartly according to the wake-up event from
Suspend-to-RAM state to
