From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935255AbdACOWW (ORCPT ); Tue, 3 Jan 2017 09:22:22 -0500 Received: from eusmtp01.atmel.com ([212.144.249.242]:23640 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934911AbdACOVy (ORCPT ); Tue, 3 Jan 2017 09:21:54 -0500 Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM. To: Rafal Ozieblo , Harini Katakam , Richard Cochran References: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com> <20170102113155.GA16373@localhost.localdomain> <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com> <20170102161359.GD3609@localhost.localdomain> CC: Andrei Pistirica , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "davem@davemloft.net" , "harini.katakam@xilinx.com" , "punnaia@xilinx.com" , "michals@xilinx.com" , "anirudh@xilinx.com" , "boris.brezillon@free-electrons.com" , "alexandre.belloni@free-electrons.com" , "tbultel@pixelsurmer.com" From: Nicolas Ferre Organization: atmel Message-ID: Date: Tue, 3 Jan 2017 15:22:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.145.133.18] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 03/01/2017 à 11:47, Rafal Ozieblo a écrit : >> From: Harini Katakam [mailto:harinikatakamlinux@gmail.com] >> Sent: 3 stycznia 2017 06:06 >> Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM. >> >> Hi Richard, >> >> On Mon, Jan 2, 2017 at 9:43 PM, Richard Cochran wrote: >>> On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote: >>>> Le 02/01/2017 à 12:31, Richard Cochran a écrit : >>>>> 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. >>> >>> It appears that this core can neither latch the time on read or write, >>> or even latch time stamps. I have worked with many different PTP HW >>> implementations, even early ones like on the ixp4xx, and it is no >>> exaggeration to say that this one is uniquely broken. >>> >>>> 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. >>> >>> Why can't you check the IP version in the driver? >> >> There is an IP revision register but it would be probably be >> better to rely on "caps" from the compatibility strings - to cover SoC specific >> implementations. Also, when this extended BD is added (with timestamp), >> additional words will need to be added statically which will be >> consistent with Andrei's CONFIG_ checks. > We can distinguish IP cores with and without PTP support by reading > Design Configuration Register. But to distinguish IP cores with > timestamps in buffer descriptors and which support only event > registers, we can only check IP version by reading the revision ID > register and base on that. > I agree with Harini, compatibility strings could be better. But we > might end up with many different configuration in the future. Compatibility strings and associated configurations are cheap. It's not a problem to have many different configurations and clearer for this particular "composite" feature. > We could use only descriptor approach but there are many Atmel's > cores on the market which support only event registers. Yes and once in silicon, it's hard to modify ;-) Regards, -- Nicolas Ferre