Thread (2 messages) 2 messages, 2 authors, 2015-06-03
DORMANTno replies
Revisions (4)
  1. v4 [diff vs current]
  2. v4 [diff vs current]
  3. v4 current
  4. v4 [diff vs current]

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

From: robh@kernel.org (Rob Herring)
Date: 2015-06-03 05:31:58
Also in: linux-rtc

Possibly related (same subject, not in this thread)

On Mon, May 18, 2015 at 1:43 PM, Robert Jarzmik [off-list ref] wrote:
Rob Herring [off-list ref] writes:
quoted
On Fri, May 15, 2015 at 6:13 AM, Robert Jarzmik [off-list ref] wrote:
quoted
Rob Herring [off-list ref] writes:
quoted
A git branch is here[4]. I've tested sa1100-rtc on PXA1928. I need help
testing on PXA27x/3xx.
Hi Rob,

I tested on PXA27x. It works for the boards which used pxa-rtc.
For the others, their defconfig become broken, because the pxa boards with
sa1100-rtc do not work anymore. And of course no .config manipulation will fix
this, because PXA architecture is denied the sa1100-rtc driver.
Ah, I didn't realize there is a mixture of use.

I could just do something like this instead of removing
sa1100_device_rtc registration:

#ifndef CONFIG_RTC_DRV_PXA
       &sa1100_device_rtc,
#else
        &pxa_device_rtc,
#endif
I ... don't like that much, especially when you consider both rtc might be
modules for example. I rather like that patch in pxa as they are.

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
 - 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.
   bootloader fidling with RTC should be considered as a source of regression.
I'm not sure that I follow.
   Moreover the first reboot will have the wrong date, until it is set.
Only for rtc1, right?

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help