lkml.org 
[lkml]   [2017]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device
From
Date
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

\
 
 \ /
  Last update: 2017-01-18 12:11    [W:0.075 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site