[PATCH 2/4] rtc: sa1100: convert to run-time register mapping

[robert.jarzmik@free.fr (Robert Jarzmik)]

Rob Herring <robh@kernel.org> writes:

>>  - adding to rtc-pxa driver :
>>    - a new rtc device (ie. it will register 2 rtc devices, one of the sa1100
>>      kind, one of the pxa specific kind)
>
> I fail to see what the rtc-pxa gets us? Something to do with which
> counter has correct time at boot? It has a rollover longer than ~126
> years is all I see. Otherwise, it looks like over-engineered h/w to
> me.
Compatibility with other OSes, for multi-OS boots, which is the main reason
rtc-pxa was developped. Of course the other OS is using the other registers,
*and* resets RCNR to 0 on boot.

>> This has flaws :
>>  - a bit of code will be duplicated between rtc-pxa and rtc-sa1100
>
> That can probably be mitigated with a common file of shared functions.
Oh yeah, I like that. Would it mean that in the future you'd have time to help
with that task ?

>>  - the ordering in rtc-pxa between the 2 rtc devices will be important, as if I
>>  remember correctly /dev/rtc points to the first /dev/rtc0 registered
>>
>> But it opens up :
>>  - DT path to both drivers
>>  - isolation between sa1100 architecture changes and pxa architecture changes
>>  - Rob's current patches can remain almost the same
>>
>>> Also note that by including the resource in rtc-sa1100's platform
>>> device resource list, you'll have stacked resources between the two
>>> platform devices appearing in /proc/iomem (you did look at that
>>> before posting the patches, right?)
>> I must admit I don't know if there are nasty consequences, I think I need to
>> follow up the code to have a clear idea.
>
> I don't follow either. The resources don't appear unless requested and
> we only have 1 driver requesting it.
There's only one small test to do to understand, as soon as I'm finished with my
zylonite's ethernet interrupts, I will make the test to understand what Russell
said, I might learn something in the test :)

Cheers.

-- 
Robert