#8843 HIGH 9.1.0: Tell userspace whether an RTC alarm woke us up.

[Zarro Boogs per Child]

#8843: Tell userspace whether an RTC alarm woke us up.
----------------------+-----------------------------------------------------
   Reporter:  cjb     |       Owner:  dsaxena      
       Type:  defect  |      Status:  new          
   Priority:  high    |   Milestone:  9.1.0        
  Component:  kernel  |     Version:  not specified
 Resolution:          |    Keywords:               
Next_action:  review  |    Verified:  0            
  Blockedby:          |    Blocking:               
----------------------+-----------------------------------------------------

Comment(by wmb at firmworks.com):

 The RTC interrupts are complicated.  There are three of them:

 a) RTC alarm interrupt[[BR]]
 b) RTC periodic interrupt[[BR]]
 c) RTC update-ended interrupt

 The periodic interrupt is routed through the 5536's "primary interrupt
 sources" block at position 8, so it can only go to IRQ8.  I'm not sure
 about the update-ended interrupt but I suspect it also goes to IRQ8 via
 the primary sources block.

 The alarm interrupt is routed separately, via the "unrestricted Y
 interrupt sources" block at position 3.  MSR 5140.0020 "PIC_YSEL_LOW" lets
 you route it to an IRQ.  The current setting of that MSR field, which OFW
 inherited from the PRS (AMD's "Preferred Register Setting" list), is 0.
 You might think that would route it to IRQ0, but it turns out that 0 means
 disabled in that case; it's not possible to route unrestricted-Y
 interrupts to IRQ0.

 So basically, with the current setting of that MSR, there's no way to make
 the RTC alarm cause an ordinary interrupt (but it can cause a wakeup, via
 the enable in the ACPI "PM1_EN" register).

 To make the RTC alarm generate an IRQ, you would have to set the
 appropriate field of MSR 5140.0020 according to this pseudocode:

 {{{
 rdmsr(0x51400020, &high, &low);
 low &= ~0xf000;
 low |= 8 << (3 * 4);
 wrmsr(0x51400020, high, low);
 }}}

 That routes the alarm to IRQ8, so it shares the same IRQ with the other
 RTC interrupts.

 To determine if the RTC alarm has fired, you can inspect the AF "alarm
 interrupts flag" - bit 5 of RTC register 0xc.

 According to my experiments with OFW, if you wakeup via an RTC alarm, that
 AF bit is *not* set, even if the corresponding enable bit is turned on in
 RTC register 0xb and the routing MSR is set to route the alarm interrupt
 to IRQ8.

 So, after a long story, I agree with what Jordan said in the last comment.

 I think it will be necessary to inspect the ACPI status register to
 determine that an alarm was the wakeup source.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8843#comment:7>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system