[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02874ECE860811409154E81DA85FBB580267C2@ORSMSX105.amr.corp.intel.com>
Date: Wed, 11 Jan 2012 17:14:43 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Richard Cochran <richardcochran@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"Ronciak, John" <john.ronciak@...el.com>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH net-next V3 1/2] igb: add PTP Hardware Clock code
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@...il.com]
> Sent: Tuesday, January 10, 2012 12:45 AM
> To: Keller, Jacob E
> Cc: netdev@...r.kernel.org; e1000-devel@...ts.sourceforge.net; Kirsher,
> Jeffrey T; Ronciak, John; John Stultz; Thomas Gleixner
> Subject: Re: [PATCH net-next V3 1/2] igb: add PTP Hardware Clock code
>
> On Mon, Jan 09, 2012 at 05:42:20PM +0000, Keller, Jacob E wrote:
>
> > Is there a reason for not using the timecounter structure from the
> > kernel? It is a layer beneath the timecompare code which is meant to
> > handle this condition. As far as I can tell this issue is solved in
> > the timecounter code. If it is not, then that should be a bug in the
> > timecounter cyclecounter code. I don't know if this issue occurs in
> > the timecounter structure because it handles the ns conversion
> > differently.
>
> My only reason is that I am not sure that the timecounter code really
> does what we need. It might well work. Consider, though, that the
> 82580 register does not overflow in the usual way. The upper 24 bits
> are always zero.
>
> What I wrote does the right thing, I think. However, duplicated
> effort is always bad, so can you show me how to change it?
>
Sure :) The way to set it up also includes the ability to specify width, so that for example the 82580 can be set to the bit length, and you provide the whole cycle counter value as a 40bit value.
I will send you a copy of the code I will be using for the ixgbe driver.
It *does* handle the conversion in a different way, because it doesn't keep an overflow counter, instead it converts "cycles" to nanoseconds. However, it claims to have support for past timestamps as long as they are within half the cycle max value.
Basically it's a portion of the code used in the timecompare stuff, but without the timecompare averaging scheme which is bad. I don't use the structure the same way that the older igb code did (because it does funky things with the 82580 and doesn't setup the other devices correctly for clock rate adjustment)
> Thanks,
> Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists