STM32L1, STM32L4 RTC: add periodic interrupts, update L1 RTC implementation
* STM32L4 RTC: add support experimental CONFIG_RTC_PERIODIC
* STM32 RTC: separate STM32L1 RTC into a separate file
STM32L1 RTC is very close to F4 or L4 versions, with two alarms
and periodic wakeup support so backported L4 peripheral to L1.
* RTC: add periodic alarms to upper and lower halves
Approved-by: Gregory Nutt <gnutt@nuttx.org>
STM32L4 RTC, PM: small fixes to subseconds handling, ADC power-management hooks
* STM32L4 ADC: add PM hooks from Motorola MDK
* STM32L4 RTC: add up_rtc_getdatetime_with_subseconds
* STM32 RTC: workaround for potential subseconds race condition
In all recent STM32 chips reading either RTC_SSR or RTC_TR is supposed to lock
the values in the higher-order calendar shadow registers until RTC_DR is read.
However many old chips have in their errata this silicon bug (at least F401xB/C,
F42xx, F43xx, L15xxE, L15xVD and likely others):
"When reading the calendar registers with BYPSHAD=0, the RTC_TR and RTC_DR
registers may not be locked after reading the RTC_SSR register. This happens
if the read operation is initiated one APB clock period before the shadow
registers are updated. This can result in a non-consistency of the three
registers. Similarly, RTC_DR register can be updated after reading the RTC_TR
register instead of being locked."
* STM32L4 RTC: correct RTC_SSR and RTC_TR read ordering
In all recent STM32 chips reading either RTC_SSR or RTC_TR is supposed to lock
the values in the higher-order calendar shadow registers until RTC_DR is read.
Change the register read ordering to match this and don't keep a workaround
for a hypothetical race condition (not in any L4 errata, lets for once assume
ST's silicon works as it is documented...)
* STM32L4 PM: remove useless #ifdefs and old non-L4 STM32 code
Approved-by: Gregory Nutt <gnutt@nuttx.org>
STM32L4: ADC, Kconfig small changes
* STM32L4 ADC: port analog watchdog ioctls from the Motorola MDK
* STM32L4: Kconfig: add some L486 and L496 chips, remove duplicates
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Actually write something to the DAC DMA buffer.
Change-Id: I1b2516ac26fb17f5242611b56be8926c5f40c2c7
Signed-off-by: Juha Niskanen <juha.niskanen@haltian.com>