SA1100/PXA RTC clean-up
Get series with b4
b4 am CAL_JsqJnj+JLFoUmE6COqhr83_H0n1=Bdk_wYnMZEzsZRu=aew@mail.gmail.comVersions newest first · linked by author and title
- v4 Latest posting 4/40 of 6 patches 0 repliesNew
- v4 posting 3/40 of 6 patches 0 repliesSuperseded
- v4 posting 2/40 of 6 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v4 posting 1/4 | 6 patches | 0 replies | Superseded |
Patches in v4 posting 4/4 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v4 yet.
Cover letter [PATCH v4 0/6] SA1100/PXA RTC clean-up
Quoted 32 lines · Robert Jarzmik
Quoted 16 lines · Rob Herring
Quoted 4 lines
I'm rather in a mood for a more aggressive approach :
- you fire an incremental patch to patch the 10 defconfigs on PXA architecture (pxa27x and pxa3xx)
Here's the breakdown of configs which enable SA1100 RTC only. Only the last 6 need to change by my count:
pxa25x
arch/arm/configs/h5000_defconfigarch/arm/configs/xcep_defconfigarch/arm/configs/viper_defconfigpxa255/270
arch/arm/configs/cm_x2xx_defconfigQuoted 6 lines
pxa270
arch/arm/configs/em_x270_defconfigarch/arm/configs/magician_defconfigarch/arm/configs/palmz72_defconfigarch/arm/configs/pcm027_defconfigarch/arm/configs/trizeps4_defconfigAnd
arch/arm/configs/jornada720_defconfigI counted wrongly as it's sa1100. So I agree with your list of last 6 defconfigs.Quoted 5 lines
Quoted 4 lines
- in this patch, you replace 's/CONFIG_RTC_DRV_SA1100/CONFIG_RTC_DRV_PXA/'
- you send this patch to the maintainers and me
- you explain in the commit message that from a userland perspective, nothing changes, except that the RTC IP will change, and any dependency on a
Quoted 8 lines
Quoted 2 lines
The IP does not change here. rtc0 is still going to be the SA1100 RTC being registered first. The only change will be the addition of rtc1.
For boards which were only using
rtc-pxa.c(as mioa701 for example), they relied on the fact that rtc0 ==pxa_rtc. Their time is stored in PXA IP. Therefore, each of their hwclock will end up on sa1100-rtc instead of pxa-rtc.So for these boards, ie. for all boards where only
rtc-pxa.cwas used, the IP addressed changes from a casual userspace perspective.
Okay, so this is the case where the time will be wrong.
I could remove the select of the sa1100-rtc and do an empty function for sa1100_rtc_init. This would preserve current behavior.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
bootloader fidling with RTC should be considered as a source of regression.
I'm not sure that I follow.
Let's talk about how a double boot windows + linux box works. The bootloader ensures that :
- sa1100-rtc holds the number of seconds since the OS start (think jiffies)
- pxa-rtc holds the wall clock time
Quoted 6 lines
Upon each reboot, sa1100-rtc is checked to see how much time has passed. If an "oustanding number" is detected, for example 10 years, the firmware resets the data partition.
Now think what will happen when this change will be commited, upon the first reboot after the linux kernel has change sa1100-rtc time.
That would be bad. But on these platforms, the kernel has been using both RTCs right? Presumably on platforms only using 1 of the RTCs, the bootloader does not touch the RTCs.
Rob
Quoted 12 lines
Quoted 3 lines
Quoted 2 lines
Moreover the first reboot will have the wrong date, until it is set.
Only for rtc1, right?
Yes, right, unless the bootloader logic is ... over-engineered.
All of this to say maintainers should be forwarned at least. After that, up to them to react.
Cheers.
--
Robert