[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20081009084210.GB30258@tekkaman>
Date: Thu, 9 Oct 2008 10:42:10 +0200
From: Rodolfo Giometti <giometti@...eenne.com>
To: john stultz <johnstul@...ibm.com>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
David Woodhouse <dwmw2@...radead.org>,
Dave Jones <davej@...hat.com>, Sam Ravnborg <sam@...nborg.org>,
Greg KH <greg@...ah.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Kay Sievers <kay.sievers@...y.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/10] PPS: low level IRQ timestamps recording.
On Wed, Oct 08, 2008 at 03:57:21PM -0700, john stultz wrote:
> Hey Rodolfo,
> First of all, kudos to your persistence on this patch set, it
> really has been a long time that you've been pushing this. Hopefully
> it won't take much longer. :)
I hope so. :)
> I've never had much experience with PPS devices, so other then knowing
> a fair number of folks who are interested in using them, most of the
> code is outside of my realm of knowledge, so I've not had much to
> comment upon.
>
> However, Thomas asked me to check and see how this interacted with the
> timekeeping subsystem, so I took another look at the current code.
> >From a quick review, I really don't see any interactions. The code
> seems fairly well isolated.
>
> One question I have is: Do you have any plans for integrating with
> the adjtimex() interface and its pps values?
Currently not.
> My only other comment is on this last patch #10, and as you said in
> your original post, its deferrable. I'd agree that dropping this patch
> for now would be best, since adding a getnstimeofday() call, which may
> take a few microseconds on common hardware, to every interrupt would
> be a bad idea.
I see... neither if we disable it by default in the configuration menu
and we remark in the help message that it could be dangerous? :P
However if that patch is blocking for the others then I prefere
dropping it.
> It seems having a special flag on the IRQ for timestamping would be
> better, and then we could only enable it for PPS connected interrupts.
> It may add a touch more jitter but I think it would allow for better
> performance while still reducing jitter.
It sounds good! But do you already have any idea about how to do it?
It's not an easy task since some drivers may not know at all that they
are managing a PPS device! As example, think about serial PPS devices,
they are managed by proper line discipline, so how can we modify the
IRQ handler behaviour at PPS source registration time?
> So yea. Unless there are objections from the serial and parallel port
> maintainers, or someone who has more experience with PPS devices and
> might better critique the API proposed, I see no reason for holding
> this patch set back from my (limited) perspective.
Thanks a lot for your time! I hope Linux may have this API support
soon! :)
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@...eenne.com
Linux Device Driver giometti@...ux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
--
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