Skip to contentSkip to conversation

MIPS: Remove the legacy RTC codes of MIPS sibyte boards

PATCH In review Mark Zhan 5 participants 7 messages Sep 30, 2007 – Oct 3, 2007 MIPS

lore
Share & tools
lore

Mark Zhan

author
#0 lore raw

PATCH 4/4 MIPS: Remove the legacy RTC codes of MIPS sibyte boards

This patch removes the legacy RTC codes of MIPS sibyte boards, which are replaced by new RTC class drivers. And a board init routine is added to register sibyte platform devices.

Signed-off-by Mark Zhan <[email protected]>
---
 arch/mips/sibyte/swarm/Makefile        |    2
 arch/mips/sibyte/swarm/rtc_m41t81.c    |  232 ---------------------------------
 arch/mips/sibyte/swarm/rtc_xicor1241.c |  209 -----------------------------
 arch/mips/sibyte/swarm/setup.c         |   56 +++++--
 4 files changed, 37 insertions(+), 462 deletions(-)
arch/mips/sibyte/swarm/Makefile +1 -1
@@ -1,3 +1,3 @@
-lib-y				= setup.o rtc_xicor1241.o rtc_m41t81.o
+lib-y				= setup.o
 
 lib-$(CONFIG_KGDB)		+= dbg_io.o
arch/mips/sibyte/swarm/rtc_m41t81.c deleted +0 -232

232 lines not on this page · raw message

arch/mips/sibyte/swarm/rtc_xicor1241.c deleted +0 -209

209 lines not on this page · raw message

arch/mips/sibyte/swarm/setup.c +36 -20

80 lines not on this page · raw message

#1 lore raw
Quoted 4 lines · Mark Zhan

This patch removes the legacy RTC codes of MIPS sibyte boards, which are replaced by new RTC class drivers. And a board init routine is added to register sibyte platform devices.

Quoted 8 lines
Signed-off-by Mark Zhan <[email protected]>
---
 arch/mips/sibyte/swarm/Makefile        |    2
 arch/mips/sibyte/swarm/rtc_m41t81.c    |  232 
 ---------------------------------
 arch/mips/sibyte/swarm/rtc_xicor1241.c |  209 -----------------------------
 arch/mips/sibyte/swarm/setup.c         |   56 +++++--
 4 files changed, 37 insertions(+), 462 deletions(-)

Patch looks okay but does not apply to the top of the -queue tree due to the dyntick patches which basically turn every piece of time code on MIPS upside down. Can you respin this patch against the -queue tree?

Thanks,

Ralf

#2 lore raw
In reply to Mark Zhan
Quoted 3 lines · Mark Zhan

This patch removes the legacy RTC codes of MIPS sibyte boards, which are replaced by new RTC class drivers. And a board init routine is added to register sibyte platform devices.

Is the system time still set correctly from the RTC chip upon bootstrap
with your changes? I cannot immediately infer it from the patches and my suspicion is it may not anymore.

Maciej

#3 lore raw
Quoted 7 lines · Maciej W. Rozycki
Quoted 3 lines

This patch removes the legacy RTC codes of MIPS sibyte boards, which are replaced by new RTC class drivers. And a board init routine is added to register sibyte platform devices.

Is the system time still set correctly from the RTC chip upon bootstrap
with your changes? I cannot immediately infer it from the patches and my suspicion is it may not anymore.

CONFIG_RTC_HCTOSYS=y can do it, isn't it?

Mark, please update defconfig files appropriately with your patch.

---
Atsushi Nemoto

#4 lore raw
Quoted 5 lines · Atsushi Nemoto
Quoted 3 lines

Is the system time still set correctly from the RTC chip upon bootstrap
with your changes? I cannot immediately infer it from the patches and my suspicion is it may not anymore.

CONFIG_RTC_HCTOSYS=y can do it, isn't it?

Hmm, I wonder whether this shouldn't be enabled via a reverse dependency.
Or even unconditionally perhaps -- if the initial system time gets set from incorrect RTC time (e.g. because it is not battery-backed) it does not get less correct than it would be otherwise, does it?

Any reason for not doing either of these?

Maciej

#5 lore raw
Quoted 4 lines · On Mon, 1 Oct 2007 20:08:55 +0100 (BST) "Maciej W. Rozycki"…
Quoted 4 lines
Quoted 3 lines

Is the system time still set correctly from the RTC chip upon bootstrap
with your changes? I cannot immediately infer it from the patches and my suspicion is it may not anymore.

Quoted 8 lines
Quoted 1 line

CONFIG_RTC_HCTOSYS=y can do it, isn't it?

Hmm, I wonder whether this shouldn't be enabled via a reverse dependency.
Or even unconditionally perhaps -- if the initial system time gets set from incorrect RTC time (e.g. because it is not battery-backed) it does not get less correct than it would be otherwise, does it?

Any reason for not doing either of these?

CONFIG_RTC_HCTOSYS defaults to YES, it should be enough...?

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it
#6 lore raw
Quoted 1 line · Alessandro Zummo

CONFIG_RTC_HCTOSYS defaults to YES, it should be enough...?

Well, yes, probably...

Maciej