[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0809041023570.3243@apollo.tec.linutronix.de>
Date: Thu, 4 Sep 2008 10:27:09 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andreas Mohr <andi@...as.de>
cc: Venki Pallipadi <venkatesh.pallipadi@...el.com>,
linux-kernel@...r.kernel.org, shaohua.li@...el.com
Subject: Re: [PATCH] Prevent clockevent event_handler ending up
handler_noop
On Thu, 4 Sep 2008, Andreas Mohr wrote:
> We'll see rather soon, since integration is finished, however I get
> MODPOST symbol link errors for clockevents_register_device() and another
> clockevent function which I forgot.
> Most certainly we should have had an EXPORT_SYMBOL_GPL() for
> these? Or are you going to tell me that modular registration won't work
> at all (yet?) for clock_event_device, as opposed to clocksource?
Should work fine. We just did not have a user yet.
> Anything else I need to take into account, other than applying the
> fixup patch in the parent post and exporting these symbols?
> And how to unregister the event device on module unload?
Not implemented :) Shouldnt be that hard, but is it worth the trouble ?
> Oh, and another question:
> Since this timer hardware was previously hooked up to an ALSA snd_timer
> (struct snd_timer_hardware), do you think changing this into
> clock_event_device provides almost equivalent service quality?
> snd_timer is used for precise MIDI timestamping (and not much else,
> thus this valuable timer was entirely unused/idle, read: wasted), I think,
> so I wonder what kind of accuracy loss (jitter, additional timer/IRQ load)
> I'd have for MIDI operation if I used this timer for the entire system's
> highres timer wheel. If you believe this is even remotely comparably robust
> as using a snd_timer-only construct, then I'm more than happy to rip out
> snd_timer and _always_ go with clock_event_device instead.
I think it should be pretty robust.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists