[PATCH v4 0/6] SA1100/PXA RTC clean-up

Rob Herring robh at kernel.org
Fri Jun 5 14:28:00 PDT 2015


On Fri, Jun 5, 2015 at 2:43 PM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> Rob Herring <robh at kernel.org> writes:
>
>>> 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_defconfig
>> arch/arm/configs/xcep_defconfig
>> arch/arm/configs/viper_defconfig
>>
>> pxa255/270
>> arch/arm/configs/cm_x2xx_defconfig
>>
>> pxa270
>> arch/arm/configs/em_x270_defconfig
>> arch/arm/configs/magician_defconfig
>> arch/arm/configs/palmz72_defconfig
>> arch/arm/configs/pcm027_defconfig
>> arch/arm/configs/trizeps4_defconfig
> And arch/arm/configs/jornada720_defconfig I counted wrongly as it's sa1100.
> So I agree with your list of last 6 defconfigs.
>
>>>  - 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
>>
>> 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.c was 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.

>
>>>    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
>
> 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

>
>>>    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



More information about the linux-arm-kernel mailing list