share sa1100 rtc driver to arch-mmp

Add resource definition of sa1100 rtc. And use ioremap to map rtc registers to avoid including address definition of rtc register. So the same driver could be shared on sa1100/pxa/mmp series.

Since there's two RTC wrappers on RTC module among PXA27x/PXA3xx/PXA95x, keep treating the two wrappers as two RTC devices will result issues of registering platform device. So only keep one RTC wrapper in these silicons.

Signed-off-by Haojian Zhuang <[email protected]>

arch/arm/mach-sa1100/generic.c +7 -0

index bb10ee2..04a62a3 100644
@@ -345,9 +345,29 @@ void sa11x0_register_irda(struct irda_platform_data *irda)
 	sa11x0_register_device(&sa11x0ir_device, irda);
 }
 
+static struct resource sa1100_rtc_resources[] = {
+	{
+		.start	= 0x90010000,
+		.end	= 0x9001003f,
+		.flags	= IORESOURCE_MEM,
+	}, {
+		.start  = IRQ_RTC1Hz,

Quoted 21 lines · Haojian Zhuang

arch/arm/mach-sa1100/generic.c +13 -0

index bb10ee2..04a62a3 100644
@@ -345,9 +345,29 @@ void sa11x0_register_irda(struct irda_platform_data *irda)
 ? ? ? sa11x0_register_device(&sa11x0ir_device, irda);
 ?}
 
+static struct resource sa1100_rtc_resources[] = {
+ ? ? {
+ ? ? ? ? ? ? .start ?= 0x90010000,
+ ? ? ? ? ? ? .end ? ?= 0x9001003f,
+ ? ? ? ? ? ? .flags ?= IORESOURCE_MEM,
+ ? ? }, {
+ ? ? ? ? ? ? .start ?= IRQ_RTC1Hz,
+ ? ? ? ? ? ? .end ? ?= IRQ_RTC1Hz,
+ ? ? ? ? ? ? .name ? = "rtc 1Hz",
+ ? ? ? ? ? ? .flags ?= IORESOURCE_IRQ,
+ ? ? }, {
+ ? ? ? ? ? ? .start ?= IRQ_RTCAlrm,
+ ? ? ? ? ? ? .end ? ?= IRQ_RTCAlrm,

arch/arm/mach-sa1100/generic.c void sa11x0_register_irda(struct irda_platform_data *irda) · line 364

Quoted 4 lines

arch/arm/mach-sa1100/generic.c +4 -0

+ ? ? ? ? ? ? .name ? = "rtc alarm",
+ ? ? ? ? ? ? .flags ?= IORESOURCE_IRQ,
+ ? ? },
+};

As I've converted all resources in this file to use the DEFINE_RES_foo() macros, it would be a shame to have this initialization reintroduced. Please use DEFINE_RES_foo() here.

From: Jett.Zhou <[email protected]>

Signed-off-by Jett.Zhou <[email protected]>

Signed-off-by Haojian Zhuang <[email protected]>

---
 arch/arm/Kconfig             |    2 +-
 arch/arm/mach-sa1100/clock.c |   91 ++++++++++++++++++++++++++++++-----------
 2 files changed, 67 insertions(+), 26 deletions(-)

From: Jett.Zhou <[email protected]>

Signed-off-by Jett.Zhou <[email protected]>

Signed-off-by Haojian Zhuang <[email protected]>

---
 arch/arm/Kconfig             |    2 +-
 arch/arm/mach-sa1100/clock.c |   91 ++++++++++++++++++++++++++++++-----------
 2 files changed, 67 insertions(+), 26 deletions(-)

arch/arm/Kconfig +1 -1

index a48aecc..6e40039 100644
@@ -754,7 +754,7 @@ config ARCH_SA1100
 	select ARCH_HAS_CPUFREQ
 	select CPU_FREQ
 	select GENERIC_CLOCKEVENTS
-	select HAVE_CLK
+	select CLKDEV_LOOKUP
 	select HAVE_SCHED_CLOCK
 	select TICK_ONESHOT
 	select ARCH_REQUIRE_GPIOLIB

arch/arm/mach-sa1100/clock.c +2 -0

index dab3c63..d6df9f6 100644
@@ -11,17 +11,39 @@
 #include <linux/clk.h>
 #include <linux/spinlock.h>
 #include <linux/mutex.h>
+#include <linux/io.h>
+#include <linux/clkdev.h>

arch/arm/mach-sa1100/clock.c +4 -0

+};
+
 struct clk {
+	const struct clkops	*ops;
+	unsigned long		rate;

arch/arm/mach-sa1100/clock.c +11 -12

+
+#define DEFINE_CLK(_name, _ops, _rate)			\
+struct clk clk_##_name = {				\
+		.ops	= _ops,				\
+		.rate	= _rate,			\
+	}
+
+static DEFINE_SPINLOCK(clocks_lock);
+
+static void clk_gpio27_enable(struct clk *clk)
 {
 	/*
 	 * First, set up the 3.6864MHz clock on GPIO 27 for the SA-1111:

@@ -32,38 +54,22 @@ static void clk_gpio27_enable(void)
 	TUCR = TUCR_3_6864MHz;
 }
 
-static void clk_gpio27_disable(void)
+static void clk_gpio27_disable(struct clk *clk)
 {
 	TUCR = 0;
 	GPDR &= ~GPIO_32_768kHz;
 	GAFR &= ~GPIO_32_768kHz;
 }
 
-static struct clk clk_gpio27;
-
-static DEFINE_SPINLOCK(clocks_lock);
-
-struct clk *clk_get(struct device *dev, const char *id)
-{
-	const char *devname = dev_name(dev);
-
-	return strcmp(devname, "sa1111.0") ? ERR_PTR(-ENOENT) : &clk_gpio27;
-}
-EXPORT_SYMBOL(clk_get);

arch/arm/mach-sa1100/clock.c +8 -0

+
+	return rate;
 }
 EXPORT_SYMBOL(clk_get_rate);
+
+const struct clkops clk_gpio27_ops = {
+	.enable		= clk_gpio27_enable,
+	.disable	= clk_gpio27_disable,
+};
+

drivers/rtc/rtc-sa1100.c +7 -0

@@ -306,6 +308,13 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
        if (!info)
                return -ENOMEM;
 
+       info->clk = clk_get(&pdev->dev, NULL);
+       if (IS_ERR(info->clk)) {
+               dev_err(&pdev->dev, "failed to find rtc clock source\n");
+               ret = PTR_ERR(info->clk);
+               goto err_clk;
+       }
+       clk_prepare_enable(info->clk);
        info->iobase = res->start;
        info->iosize = resource_size(res);
        info->irq_1hz = irq_1hz;

Quoted 16 lines · Haojian Zhuang

(quoted diff) +7 -0

@@ -306,6 +308,13 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
 ? ? ? ? if (!info)
 ? ? ? ? ? ? ? ? return -ENOMEM;
 
+ ? ? ? info->clk = clk_get(&pdev->dev, NULL);
+ ? ? ? if (IS_ERR(info->clk)) {
+ ? ? ? ? ? ? ? dev_err(&pdev->dev, "failed to find rtc clock source\n");
+ ? ? ? ? ? ? ? ret = PTR_ERR(info->clk);
+ ? ? ? ? ? ? ? goto err_clk;
+ ? ? ? }
+ ? ? ? clk_prepare_enable(info->clk);
 ? ? ? ? info->iobase = res->start;
 ? ? ? ? info->iosize = resource_size(res);
 ? ? ? ? info->irq_1hz = irq_1hz;

@@ -379,6 +388,9 @@ err_dev:
 ? ? ? ? iounmap(info->reg_base);

Quoted 7 lines

?err_map:
? ? ? ? platform_set_drvdata(pdev, NULL);
+ ? ? ? clk_disable_unprepare(info->clk);
+ ? ? ? clk_put(info->clk);
+err_clk:
? ? ? ? kfree(info);
? ? ? ? return ret;

I wonder whether it would be easier to just make the clk handling conditional here, like

? ? ? ?info->clk = clk_get(&pdev->dev, NULL);
? ? ? ?if (PTR_ERR(info->clk) == -ENOENT)
? ? ? ? ? ? ? ?info->clk = NULL;
? ? ? ?if (IS_ERR(info->clk)) {
? ? ? ? ? ? ? ?ret = ?PTR_ERR(info->clk);
? ? ? ? ? ? ? ?goto err_clk;
? ? ? ?}

? ? ? ?if (info->clk)
? ? ? ? ? ? ? ?clk_prepare_enable(info->clk);
? ? ? ?...
? ? ? ?if (info->clk) {
? ? ? ? ? ? ? ?clk_disable_unprepare(info->clk);
? ? ? ? ? ? ? ?clk_put(info->clk);
? ? ? ?}

With this, you would no longer need to add dummy clocks in platforms that really have no clock handling.

? ? ? ?Arnd

Quoted 18 lines · Haojian Zhuang

drivers/rtc/rtc-sa1100.c +7 -0

@@ -306,6 +308,13 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
        if (!info)
                return -ENOMEM;
 
+       info->clk = clk_get(&pdev->dev, NULL);
+       if (IS_ERR(info->clk)) {
+               dev_err(&pdev->dev, "failed to find rtc clock source\n");
+               ret = PTR_ERR(info->clk);
+               goto err_clk;
+       }
+       clk_prepare_enable(info->clk);
        info->iobase = res->start;
        info->iosize = resource_size(res);
        info->irq_1hz = irq_1hz;

@@ -379,6 +388,9 @@ err_dev:
        iounmap(info->reg_base);
 err_map:
        platform_set_drvdata(pdev, NULL);

drivers/rtc/rtc-sa1100.c err_dev: · line 395

Quoted 5 lines

drivers/rtc/rtc-sa1100.c +3 -0

+       clk_disable_unprepare(info->clk);
+       clk_put(info->clk);
+err_clk:
        kfree(info);
        return ret;

I wonder whether it would be easier to just make the clk handling conditional here, like

Eww. No, just keep this hidden beneath the clk API. Return a NULL clock for this device, and ensure that all the standard clk API functions know internally that that means 'no action required'.

There's no need to pollute drivers with this platform specific knowledge.

Review static int sa1100_rtc_probe(struct platform_device *pdev) · line 317

Quoted 11 lines · Haojian Zhuang

(quoted diff) +7 -0

@@ -306,6 +308,13 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
 ? ? ? if (!info)
 ? ? ? ? ? ? ? return -ENOMEM;
 
+ ? ? info->clk = clk_get(&pdev->dev, NULL);
+ ? ? if (IS_ERR(info->clk)) {
+ ? ? ? ? ? ? dev_err(&pdev->dev, "failed to find rtc clock source\n");
+ ? ? ? ? ? ? ret = PTR_ERR(info->clk);
+ ? ? ? ? ? ? goto err_clk;
+ ? ? }
+ ? ? clk_prepare_enable(info->clk);

What about checking for errors from clk_prepare_enable() ?

I assume that this is the clock required to access the peripheral, rather than the timekeeping clock? ?If so, does it need to be kept enabled all the time the driver is probed, or can the clock be prepared & enabled and disabled & unprepared when the device is opened/closed ?

Quoted 15 lines · Russell King - ARM Linux

Review static int sa1100_rtc_probe(struct platform_device *pdev) · line 317

Quoted 11 lines · Haojian Zhuang

(quoted diff) +7 -0

@@ -306,6 +308,13 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
 ? ? ? if (!info)
 ? ? ? ? ? ? ? return -ENOMEM;
 
+ ? ? info->clk = clk_get(&pdev->dev, NULL);
+ ? ? if (IS_ERR(info->clk)) {
+ ? ? ? ? ? ? dev_err(&pdev->dev, "failed to find rtc clock source\n");
+ ? ? ? ? ? ? ret = PTR_ERR(info->clk);
+ ? ? ? ? ? ? goto err_clk;
+ ? ? }
+ ? ? clk_prepare_enable(info->clk);

What about checking for errors from clk_prepare_enable() ?

Quoted 5 lines

I assume that this is the clock required to access the peripheral, rather than the timekeeping clock? ?If so, does it need to be kept enabled all the time the driver is probed, or can the clock be prepared & enabled and disabled & unprepared when the device is opened/closed ?

Since some platform code is using RTC register in their suspend/resume routine, I have to always enable the clock of rtc module.

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

Quoted 2 lines

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

looks gine

Best Regards,
J.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

Quoted 2 lines · Haojian Zhuang

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

What is the status of the drivers/rtc/rtc-pxa.c driver after this series? Is is still required for some pxa machines or can it get removed now? It seems a little strange to register two platform devices for the rtc on each pxa machine, with the same resources.

? ? ? ?Arnd

Quoted 4 lines · Arnd Bergmann

Quoted 2 lines · Haojian Zhuang

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

Quoted 4 lines

What is the status of the drivers/rtc/rtc-pxa.c driver after this series? Is is still required for some pxa machines or can it get removed now? It seems a little strange to register two platform devices for the rtc on each pxa machine, with the same resources.

Yes, it's very strange to support two RTC wrappers at the same time. So rtc-pxa is removed in pxa27x/pxa3xx after this patch series. It only exists in pxa95x.

Quoted 5 lines · Haojian Zhuang

Quoted 4 lines · Arnd Bergmann

Quoted 2 lines · Haojian Zhuang

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.

Quoted 8 lines

Quoted 4 lines

What is the status of the drivers/rtc/rtc-pxa.c driver after this series? Is is still required for some pxa machines or can it get removed now? It seems a little strange to register two platform devices for the rtc on each pxa machine, with the same resources.

Yes, it's very strange to support two RTC wrappers at the same time. So rtc-pxa is removed in pxa27x/pxa3xx after this patch series. It only exists in pxa95x.

What is the reason for this? Wouldn't it be easier to move pxa95x over to use the same driver as well? I guess that can be a series for another time, but it seems like you are almost at the point where you can remove the other driver entirely.

? ? ? ?Arnd

From another view, there're more features in new wrapper. It should be

I can remove the rtc-pxa support entirely. I still want to leave this since this may be the only one choice in the future silicons.

Since some boards with pxa27x/pxa3xx are accessing RCNR (the old rtc wrapper) directly, I use rtc-sa1100 to keep consistently. In pxa95x, nobody is using the old rtc wrapper directly. So I only use it in pxa95x.

Quoted 7 lines · Haojian Zhuang

I can remove the rtc-pxa support entirely. I still want to leave this since this may be the only one choice in the future silicons.

Since some boards with pxa27x/pxa3xx are accessing RCNR (the old rtc wrapper) directly, I use rtc-sa1100 to keep consistently. In pxa95x, nobody is using the old rtc wrapper directly. So I only use it in pxa95x.

No, I don't agree there.

The PXA RTC silicon support 2 different set of registers to access time :
?- RCNR (rtc-sa1100)
?- RYCR/RDCR (rtc-pxa)

The rtc-pxa driver was created to provide support for boards using the RYCR/RDCR rather than RCNR.

Therefore I'm against removing rtc-pxa, unless there is a driver for pxa, which provides RTC using RYCR/RDCR registers.

We had that discussion a long time ago, in [1].

Hi Robert,

I hadn't any plan to remove rtc-pxa driver. I only disabled it for pxa27x/pxa3xx. Please check the code of arch/arm/mach-pxa/sharpsl_pm.c. If we only enable rtc-pxa on pxa27x, we'll break the behavior on sharpsl since it's using rtc-sa1100. In order to keep code consistently, I disable rtc-pxa on pxa27x/pxa3xx.

Quoted 7 lines · Haojian Zhuang

Hi Robert,

I hadn't any plan to remove rtc-pxa driver. I only disabled it for pxa27x/pxa3xx. Please check the code of arch/arm/mach-pxa/sharpsl_pm.c. If we only enable rtc-pxa on pxa27x, we'll break the behavior on sharpsl since it's using rtc-sa1100. In order to keep code consistently, I disable rtc-pxa on pxa27x/pxa3xx.

Then you'll break mioa701 board, which is pxa270 based. The RYCR/RDCR were introduced on PXA27x chips, so the rtc-pxa driver should work on pxa27x SoCs.

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

Quoted 5 lines · Robert Jarzmik

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Quoted 4 lines

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

How about to move the rtc-sa1100 or rtc-pxa device register from pxa27x.c to board file? Then we'll be both happy.

Quoted 6 lines · Haojian Zhuang

Quoted 5 lines · Robert Jarzmik

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Quoted 7 lines

Quoted 4 lines

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

How about to move the rtc-sa1100 or rtc-pxa device register from pxa27x.c to board file? Then we'll be both happy.

How about stopping thinking about "one or other" and start thinking "both" ? The RTC library can and does cope with more than one RTC, and each RTC is exposed uniquely to userspace. ?So there shouldn't be any problem in keeping both around, or even registering both together.

You just have to make sure you don't use both of them together as their open functions will want to claim the same IRQ. ?That's not really a problem because that should provide exclusivity between the two.

Quoted 20 lines · Russell King - ARM Linux

Quoted 6 lines · Haojian Zhuang

Quoted 5 lines · Robert Jarzmik

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Quoted 7 lines

Quoted 4 lines

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

How about to move the rtc-sa1100 or rtc-pxa device register from pxa27x.c to board file? Then we'll be both happy.

How about stopping thinking about "one or other" and start thinking "both" ? The RTC library can and does cope with more than one RTC, and each RTC is exposed uniquely to userspace. ?So there shouldn't be any problem in keeping both around, or even registering both together.

Quoted 3 lines

You just have to make sure you don't use both of them together as their open functions will want to claim the same IRQ. ?That's not really a problem because that should provide exclusivity between the two.

Resource is bind with platform device. We'll meet resource conflict if we register them both.

Quoted 22 lines · Haojian Zhuang

Quoted 20 lines · Russell King - ARM Linux

Quoted 6 lines · Haojian Zhuang

Quoted 5 lines · Robert Jarzmik

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Quoted 7 lines

Quoted 4 lines

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

How about to move the rtc-sa1100 or rtc-pxa device register from pxa27x.c to board file? Then we'll be both happy.

How about stopping thinking about "one or other" and start thinking "both" ? The RTC library can and does cope with more than one RTC, and each RTC is exposed uniquely to userspace. ?So there shouldn't be any problem in keeping both around, or even registering both together.

Quoted 6 lines

Quoted 3 lines

You just have to make sure you don't use both of them together as their open functions will want to claim the same IRQ. ?That's not really a problem because that should provide exclusivity between the two.

Resource is bind with platform device. We'll meet resource conflict if we register them both.

Ok, in that case we need patch 3 split up such that we can move forward and get some of the build errors fixed.

That probably means that the first half of patch 3 should be providing the IRQs and only the IRQs to the driver, and the driver making use of that information. Nothing more than that - not even the differing register offsets.

The next stage would be to introduce the different device names, and use that to chose the different register layouts - but still using a hard coded base address. That will involve adding a new define for this to both arch/arm/mach-sa1100/include/mach/SA-1100.h and arch/arm/mach-pxa/include/mach/regs-rtc.h. At the same time, this patch should move the register definitions from those headers into the sa1100 RTC driver, and get rid of the virtual address definitions for these registers.

The clocking issues can also be sorted out as well without solving the base address issue - and that gets most of this patch set ready for merging without causing Robert any problems.

I would like to see this ASAP so that the current build regression with PXA can be fixed.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 22 lines · Haojian Zhuang

Quoted 20 lines · Russell King - ARM Linux

Quoted 6 lines · Haojian Zhuang

Quoted 5 lines · Robert Jarzmik

The behaviour should be as before, the config should be able to choose between rtc-pxa and rtc-sa1100 for a pxa27x based board. For sharpsl_pm, I suppose the rtc-sa1100 will be chosen in the .config, and for mioa701, it will be rtc-pxa.

Quoted 7 lines

Quoted 4 lines

Just to clear, I'm against removing "resources, clock" from pxa27x platform code which would break rtc-pxa driver on pxa27x. Now I don't care if you're talking about changing some "defconfigs".

How about to move the rtc-sa1100 or rtc-pxa device register from pxa27x.c to board file? Then we'll be both happy.

How about stopping thinking about "one or other" and start thinking "both" ? The RTC library can and does cope with more than one RTC, and each RTC is exposed uniquely to userspace. ?So there shouldn't be any problem in keeping both around, or even registering both together.

Quoted 6 lines

Quoted 3 lines

You just have to make sure you don't use both of them together as their open functions will want to claim the same IRQ. ?That's not really a problem because that should provide exclusivity between the two.

Resource is bind with platform device. We'll meet resource conflict if we register them both.

Ok, in that case we need patch 3 split up such that we can move forward and get some of the build errors fixed.

That probably means that the first half of patch 3 should be providing the IRQs and only the IRQs to the driver, and the driver making use of that information. ?Nothing more than that - not even the differing register offsets.

The next stage would be to introduce the different device names, and use that to chose the different register layouts - but still using a hard coded base address. ?That will involve adding a new define for this to both arch/arm/mach-sa1100/include/mach/SA-1100.h and arch/arm/mach-pxa/include/mach/regs-rtc.h. ?At the same time, this patch should move the register definitions from those headers into the sa1100 RTC driver, and get rid of the virtual address definitions for these registers.

The clocking issues can also be sorted out as well without solving the base address issue - and that gets most of this patch set ready for merging without causing Robert any problems.

I would like to see this ASAP so that the current build regression with PXA can be fixed.

OK. I can keep the hard coded register definition and format patch right now. The rtc register base of arch-sa1100, arch-pxa, arch-mmp are different. It means
that I need use #ifdef CONFIG_ARCH to distinguish different arch. But I have a question that removing #ifdef CONFIG_ARCH in driver code is our target, isn't it?

Remove the hardcode definition of rtc registers, use ioremap() instead. Append clk support for arch-mmp, so add dummy clk in arch-sa1100/arch-pxa.