Re: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device
From: Andy Shevchenko
Date: Wed Jan 18 2017 - 06:10:39 EST
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@xxxxxxxxxxxxxxx>
Intel Finland Oy