Re: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, 2017-01-18 at 11:24 +0100, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Andy Shevchenko wrote:
> 
> > On Mon, 2017-01-16 at 22:00 +0100, Thomas Gleixner wrote:
> > 
> > > The early callback does not work, but we have one which is invoked
> > > later
> > > on: x86_init.wallclock_init(). That's invoked after the (IO/APIC)
> > > setup has
> > > been completed. See patch below.
> > 
> > Unfortunately it is till too early. Looks like descriptors are not
> > available yet and we still can't get an allocation:
> > 
> > [    0.000000] intel_mid: Failed to allocate RTC interrupt.
> > Disabling
> > RTC
> > 
> > ...
> > 
> > [    0.000000] NR_IRQS:4352 nr_irqs:512 0
> 
> Indeed. Did not think about that we need the irq subsystem up not only
> the
> primary IOAPIC init done.
> 
> Looking deeper it's actually simple. MID already overloads the
> timer_init()
> setup function. So we can just do it there.

Yes, it does. However I have another solution, just would like to
discuss.

There is a timekeeping_init() call, which is a first user of the RTC.
I have 3 changes:
- introduce arch_pre_timekeeping_init() and move wallclock_init() call
there
- use almost your initial suggestion
- move wallclock_init() to x86_platform and rename to init_wallclock()
to be consistent with the rest of wallclock API (this, though, has item
to discuss, i.e. __init use for callbacks)

This would allow to clearly initialize virtual RTC or legacy one at the
same know point.

What do you think? Should I send a series for review?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy