linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/6] SA1100/PXA RTC clean-up
Date: Fri, 05 Jun 2015 21:43:04 +0200	[thread overview]
Message-ID: <871thq54c7.fsf@belgarion.home> (raw)
In-Reply-To: <CAL_JsqKWNNH4stY+CNtKCiE7qcwDYaxZc36-iqqe1ddmG82g1Q@mail.gmail.com> (Rob Herring's message of "Wed, 3 Jun 2015 00:31:58 -0500")

Rob Herring <robh@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.

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

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

  reply	other threads:[~2015-06-05 19:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 15:02 [PATCH v4 0/6] SA1100/PXA RTC clean-up Rob Herring
2015-05-13 15:02 ` [PATCH v4 1/6] rtc: sa1100: prepare to share sa1100_rtc_ops Rob Herring
2015-05-13 15:02 ` [PATCH v4 2/6] rtc: pxa: convert to use shared sa1100 functions Rob Herring
2015-05-13 15:02 ` [PATCH v4 3/6] ARM: pxa: add memory resource to SA1100 RTC device Rob Herring
2015-05-13 15:02 ` [PATCH v4 4/6] rtc: sa1100/pxa: convert to run-time register mapping Rob Herring
2015-05-13 15:02 ` [PATCH v4 5/6] ARM: sa1100: remove unused RTC register definitions Rob Herring
2015-05-13 15:02 ` [PATCH v4 6/6] ARM: mmp: " Rob Herring
2015-05-15 11:13 ` [PATCH v4 0/6] SA1100/PXA RTC clean-up Robert Jarzmik
2015-05-18 13:18   ` Rob Herring
2015-05-18 18:43     ` Robert Jarzmik
2015-06-03  5:31       ` Rob Herring
2015-06-05 19:43         ` Robert Jarzmik [this message]
2015-06-05 21:28           ` Rob Herring
2015-06-06 21:25             ` Robert Jarzmik
2015-06-08 16:52               ` Rob Herring
2015-06-14  8:11                 ` Robert Jarzmik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871thq54c7.fsf@belgarion.home \
    --to=robert.jarzmik@free.fr \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).