[PATCH 0/7] share sa1100 rtc driver to arch-mmp

[Russell King - ARM Linux]

On Thu, Feb 23, 2012 at 10:49:37AM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 23, 2012 at 06:22:23PM +0800, Haojian Zhuang wrote:
> > On Thu, Feb 23, 2012 at 6:00 PM, Russell King - ARM Linux
> > <linux at arm.linux.org.uk> wrote:
> > > On Thu, Feb 23, 2012 at 05:45:20PM +0800, Haojian Zhuang wrote:
> > >> On Thu, Feb 23, 2012 at 4:52 PM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> > >> > 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".
> > >> >
> > >>
> > >> 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.
> > 
> > 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.

Note: I think that should be done even though sharpsl_pm and miao both
access the RTC registers directly, even though it means duplicating the
definitions.

In the long run, someone needs to look at whether sharpsl_pm can be made
to use the alarmtimer stuff (kernel/time/alarmtimer.c) but that's a
project for someone with a Zaurus to do.  No one else can do it.

> 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