[RFC PATCH 00/16] Consolidation: move SMP local timers to driver/clocksource

[Grant Likely]

On Mon, Jun 20, 2011 at 2:32 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Jun 20, 2011 at 09:25:30AM +0100, Marc Zyngier wrote:
>> On 17/06/11 18:25, Rob Herring wrote:
>> > If this is the direction to go, then there are a lot of other timers
>> > that can be moved besides just local timers. But Russell didn't really
>> > like the shmobile patches for early platform devices which this relies
>> > on. So we should get agreement on the small bit of infrastructure needed
>> > first, then start moving individual timers.
>>
>> I'm open to suggestions. Should the early platform infrastructure be
>> flagged as unsuitable, I'd be happy to switch to something else, as long
>> as it is minimal, and does not create another ARM-specific API (been
>> there, done that...).
>
> I am most certainly not a fan of the early platform device stuff as I've
> said in the past.
>
> It looks to me like:
>
> 1. it's overcomplex and fragile.
> 2. it abuses the early command line system.
> 3. it abuses platform devices etc.
> 4. it requires more initialization calls.
>
> Lastly, and probably more importantly for the direction we're going, I
> can't see how it would hook into DT other than using the DT provided
> command line, which also appears to be an abuse there too.

I'm going to second that opinion.  I just looked through the early
platform stuff, and I'm not thrilled with the model.

Setting up timers does not need to plug into the device model.  Unless
I'm completely reading the ARM code wrong, these timers are pretty
fundamental to the operating system, and thus aren't really like other
devices.  I don't see any problem with individual timer init functions
populated in machine_desc assuming that multiple boards with the same
SoC will not require different timer initialization.

g.