All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vick, Matthew" <matthew.vick@intel.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: "e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: igb: acknowledging time sync interrupts
Date: Tue, 28 May 2013 15:20:10 +0000	[thread overview]
Message-ID: <CDCA1885.1E850%matthew.vick@intel.com> (raw)
In-Reply-To: <20130526103900.GA11682@netboy>

On 5/26/13 3:39 AM, "Richard Cochran" <richardcochran@gmail.com> wrote:

>Matt,
>
>In igb_main.c you have ISR code like:
>
>	if (icr & E1000_ICR_TS) {
>		u32 tsicr = rd32(E1000_TSICR);
>
>		if (tsicr & E1000_TSICR_TXTS) {
>			/* acknowledge the interrupt */
>			wr32(E1000_TSICR, E1000_TSICR_TXTS);
>			/* retrieve hardware timestamp */
>			schedule_work(&adapter->ptp_tx_work);
>		}
>	}
>
>In the datasheet for the 82580 and the i210, for TSICR it says,
>
>   Note: Once ICR.Time_Sync is set, the internal value of this
>         register should be cleared by writing 1b to all bits
>         or cleared by a read to enable receiving an additional
>         ^^^^^^^^^^^^^^^^^^^^
>         ICR.Time_Sync interrupt.
>
>and that implies that your write to acknowledge the interrupt is
>superfluous, since you already read the TSICR.
>
>Is this an error in the datasheets, or is the code doing extra,
>unneeded work?
>
>Thanks,
>Richard

Richard,

Good catch--and you're correct--but I had issues with the read of TSICR
not clearing like it should on the 82580 (but it would work fine on the
I350 and I210). I decided the cleaner implementation would be to
explicitly acknowledge the interrupt across the board. I haven't had the
time to follow up with the hardware team, but my suspicion is that it's an
errata with the 82580.

I'll start some internal discussion to see if I can get an official answer
on the 82580.

Cheers,
Matthew


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

  reply	other threads:[~2013-05-28 15:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-26 10:39 igb: acknowledging time sync interrupts Richard Cochran
2013-05-28 15:20 ` Vick, Matthew [this message]
2013-05-28 16:06   ` Richard Cochran
2013-05-29 17:42     ` Vick, Matthew

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CDCA1885.1E850%matthew.vick@intel.com \
    --to=matthew.vick@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.