Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel,

On Thu, Sep 13, 2018 at 3:17 PM Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
> On 11/09/2018 20:42, Chris Brandt wrote:
> > On Tuesday, September 11, 2018 1, Rob Herring wrote:
> >> Well before we get to initcalls, the kernel calls the arch specific
> >> time_init() which (on ARM) calls of_clk_init (for all the reasons
> >> above) and then timer_probe(). When timer_probe returns, it is
> >> expected that you have setup a clocksource and clockevent. If you
> >> haven't, then at some point before we get to initcalls we should hang
> >> because we're not getting any timer interrupts and time is not
> >> advancing.
> >
> > What I get now is:
> >
> > [    0.000000] timer_probe: no matching timers found
> > ...
> > ...
> >  [    0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> > ...
> > ...
> >
> >
> > But then later on in boot, I'll get (with my subsys_initcall timer fix)
> >
> > ...
> > ...
> > [    0.000000] SCSI subsystem initialized
> > [    0.000000] usbcore: registered new interface driver usbfs
> > [    0.000000] usbcore: registered new interface driver hub
> > [    0.000000] usbcore: registered new device driver usb
> > [    0.000000] clocksource: ostm: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 28958491609 ns
> > [    0.000619] sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 32537631224ns
> > [    0.008599] ostm: used for clocksource
> > [    0.018926] ostm: used for clock events
> > [    0.133339] clocksource: Switched to clocksource ostm
> > [    0.821474] NET: Registered protocol family 2
> > [    0.840624] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
> > [    0.850549] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
> > ...
> > ...
> >
> >
> >
> >> Maybe you
> >> just get lucky and it works as long as no thread blocks (e.g. on a
> >> msleep).
> >
> > You're right. If I put in a msleep() before my timer is up and running, it hangs.
> >
> > As far as I can tell, nothing before device_initcall seems to call anything like msleep.
> >
> >> If things changed and you can setup a timer in an initcall,
> >> then why are folks still trying to do things like early platform
> >> drivers. Regular drivers would work and we should be able to
> >> completely remove CLK_OF_DECLARE and TIMER_OF_DECLARE.
> >
> > I wonder if the reason is because you can't assign a priority to your
> > driver when you declare it with xxx_initcall( ). So, your driver ends up
> > in the same table as all the other drivers and you are not guaranteed the
> > order in which they probe. So, the answer was to make a NEW table and
> > register it using TIMER_OF_DECLARE and CLOCK_OF_DECLARE.
> >
> > I wonder they just didn't make a clock_initcall() and timer_initcall()
> > instead.
>
> What happens if you place the clk_init() before board_time_init() ? in
> arch/sh/kernel/time.c

Nothing, as Chris is using an ARM platform ;-)

The clock driver is drivers/clk/renesas/renesas-cpg-mssr.c, which is a
platform_driver registered from subsys_initcall().

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux