linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Richard Cochran <richardcochran@gmail.com>,
	Rafal Ozieblo <rafalo@cadence.com>
Cc: Andrei Pistirica <andrei.pistirica@microchip.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"harinikatakamlinux@gmail.com" <harinikatakamlinux@gmail.com>,
	"harini.katakam@xilinx.com" <harini.katakam@xilinx.com>,
	"punnaia@xilinx.com" <punnaia@xilinx.com>,
	"michals@xilinx.com" <michals@xilinx.com>,
	"anirudh@xilinx.com" <anirudh@xilinx.com>,
	"boris.brezillon@free-electrons.com" 
	<boris.brezillon@free-electrons.com>,
	"alexandre.belloni@free-electrons.com" 
	<alexandre.belloni@free-electrons.com>,
	"tbultel@pixelsurmer.com" <tbultel@pixelsurmer.com>
Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
Date: Mon, 2 Jan 2017 15:47:07 +0100	[thread overview]
Message-ID: <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com> (raw)
In-Reply-To: <20170102113155.GA16373@localhost.localdomain>

Le 02/01/2017 à 12:31, Richard Cochran a écrit :
> On Mon, Jan 02, 2017 at 09:36:10AM +0000, Rafal Ozieblo wrote:
>> According Cadence Hardware team:
>> "It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
>> The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
>> The question is are you sure that you read timestamp for current frame? (not for the next frame).
> 
> AFAICT, having the time stamp in the descriptor is not universally
> supported.  Looking at the Xilinx Zynq 7000 TRM, I can't find any
> mention of this.

This is why I proposed to address options incrementally: without
timestamp support in descriptor (this patch series), then adding this
feature in another patch series.

Rafal, this is why Andrei noted that the case covered by this series is
not adapted to GEM-GXL and doesn't address the "timestamp in descriptor"
case.

> This Cadence IP core is a complete disaster.

Well, it evolved and propose several options to different SoC
integrators. This is not something unusual...
I suspect as well that some other network adapters have the same
weakness concerning PTP timestamp in single register as the early
revisions of this IP.

> Unless someone can tell us how this IP works in all of its
> incarnations, this series is going nowhere.

We're already as v4 (thanks to your fruitful contributions BTW) for this
series and will try to add features for other IP options & revisions
incrementally.
I suspect that Rafal tend to jump too quickly to the latest IP revisions
and add more options to this series: let's not try to pour too much
things into this code right now.

FYI, Andrei will be back online next week.

Regards,
-- 
Nicolas Ferre

  parent reply	other threads:[~2017-01-02 14:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 12:56 [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM Andrei Pistirica
2016-12-14 12:56 ` [RFC PATCH net-next v4 2/2] macb: Enable 1588 support in SAMA5Dx platforms Andrei Pistirica
2016-12-20 16:38   ` Rafal Ozieblo
2016-12-28  8:15 ` [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM Richard Cochran
2016-12-28 13:23 ` Rafal Ozieblo
2017-01-02  9:36 ` Rafal Ozieblo
2017-01-02 11:31   ` Richard Cochran
2017-01-02 11:43     ` Harini Katakam
2017-01-02 16:03       ` Richard Cochran
2017-01-02 14:47     ` Nicolas Ferre [this message]
2017-01-02 16:13       ` Richard Cochran
2017-01-03  5:06         ` Harini Katakam
2017-01-03 10:20           ` Richard Cochran
2017-01-03 10:29           ` Richard Cochran
2017-01-03 10:48             ` Harini Katakam
2017-01-03 10:47           ` Rafal Ozieblo
2017-01-03 11:14             ` Richard Cochran
2017-01-11 14:34               ` Andrei.Pistirica
2017-01-03 14:22             ` Nicolas Ferre

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=0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=andrei.pistirica@microchip.com \
    --cc=anirudh@xilinx.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=davem@davemloft.net \
    --cc=harini.katakam@xilinx.com \
    --cc=harinikatakamlinux@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michals@xilinx.com \
    --cc=netdev@vger.kernel.org \
    --cc=punnaia@xilinx.com \
    --cc=rafalo@cadence.com \
    --cc=richardcochran@gmail.com \
    --cc=tbultel@pixelsurmer.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).