Skip to content
  • Anthony Olech's avatar
    drivers/rtc/rtc-da9052.c: ALARM causes interrupt storm · 7c994c08
    Anthony Olech authored
    
    
    Setting the alarm to a time not on a minute boundary results in repeated
    interrupts being generated by the DA9052/3 PMIC device until the kernel
    RTC core sees that the alarm has rung.  Sometimes the number and frequency
    of interrupts can cause the kernel to disable the IRQ line used by the
    DA9052/3 PMIC with disasterous consequences.  This patch fixes the
    problem.
    
    Even though the DA9052/3 PMIC is capable generating periodic interrupts,
    ie TICKS, the method used to distinguish RTC_AF from RTC_PF events was
    flawed and can not work in conjunction with the regmap_irq kernel core.
    Thus that flawed detection has also been removed by the DA9052/3 PMIC RTC
    driver's irq handler, so that it no longer reports the wrong type of event
    to the kernel RTC core.
    
    The internal static functions within the DA9052/3 PMIC RTC driver have
    been changed to pass the 'da9052_rtc' structure instead of the 'da9052'
    because there is no backwards pointer from the 'da9052' structure.
    
    This patch fixes the three issues described above.  The first is serious
    because usiing the RTC alarm set to a non minute boundary will eventually
    cause all component drivers that depend on the interrupt line to fail.
    The solution adopted is to round up to alarm time to the next highest
    minute.
    
    The second bug, reporting a RTC_PF event instead of an RTC_AF event turns
    out to not matter with the current implementation of the kernel RTC core
    as it seems to ignore the event type.  However, should that change in the
    future it is better to fix the issue now and not have 'problems waiting to
    happen'
    
    The third set of changes are to make the da9052_rtc structure available to
    all the local internal functions in the driver.  This was done during
    testing so that diagnostic data could be stored there.  Should the
    solution to the first issue be found not acceptable, then the alternative
    of using the TICKS interrupt at the fixed one second interval in order to
    step to the exact second of the requested alarm requires an extra (alarm
    time) piece of data to be stored.  In devices that use the alarm function
    to wake up from sleep, accuracy to the second will result in the device
    being awake for up to nearly a minute longer than expected.
    
    Signed-off-by: default avatarAnthony Olech <anthony.olech.opensource@diasemi.com>
    Cc: David Dajun Chen <dchen@diasemi.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    7c994c08