Messages in this thread | | | Subject | Re: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device | From | Andy Shevchenko <> | Date | Wed, 18 Jan 2017 12:56:27 +0200 |
| |
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
| |