On Wed, 2 Apr 2014 12:45:38 +0100 "Opensource [Anthony Olech]" <[email protected]> wrote:
> 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. > > Signed-off-by: Anthony Olech <[email protected]> > --- > > This patch is relative to linux-next repository tag next-20140402 > > 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. The above three paragraphs contained important info which is appropriate to the formal patch changelog. > > ... > > @@ -261,7 +271,7 @@ static struct platform_driver da9052_rtc_driver = { > > module_platform_driver(da9052_rtc_driver); > > -MODULE_AUTHOR("David Dajun Chen <[email protected]>"); > +MODULE_AUTHOR("Anthony Olech <[email protected]>"); > MODULE_DESCRIPTION("RTC driver for Dialog DA9052 PMIC"); > MODULE_LICENSE("GPL"); > MODULE_ALIAS("platform:da9052-rtc"); What's this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
