Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754629AbcKUPFK (ORCPT ); Mon, 21 Nov 2016 10:05:10 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:56939 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753700AbcKUPFH (ORCPT ); Mon, 21 Nov 2016 10:05:07 -0500 Subject: Re: Synopsys Ethernet QoS Driver To: Joao Pinto , Rayagond Kokatanur , Rabin Vincent References: <1dbb6047-2bbb-4d56-2a62-ab65a0254844@synopsys.com> <20161119135654.GA14079@lnxartpec.se.axis.com> <1248f4ce-4859-10e6-fef9-342ea543f8d4@synopsys.com> <87c8a24b-0812-7850-cb3f-7be691bab432@st.com> <937252db-9538-2cf6-c8fa-82b558531c51@st.com> <48776f8b-4e06-1456-1b52-3ea08a22b2a4@synopsys.com> CC: mued dib , David Miller , Jeff Kirsher , , , , netdev , , , , , , "linux-arm-kernel@lists.infradead.org" From: Giuseppe CAVALLARO Message-ID: <7318c77e-3011-03f3-e673-54e3bb0554aa@st.com> Date: Mon, 21 Nov 2016 16:03:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <48776f8b-4e06-1456-1b52-3ea08a22b2a4@synopsys.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.52.139.54] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-21_13:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2186 Lines: 60 On 11/21/2016 4:00 PM, Joao Pinto wrote: > On 21-11-2016 14:36, Giuseppe CAVALLARO wrote: >> Hello Joao >> >> On 11/21/2016 2:48 PM, Joao Pinto wrote: >>> Synopsys QoS IP is a separated hardware component, so it should be reusable by >>> all implementations using it and so have its own "core driver" and platform + >>> pci glue drivers. This is necessary for example in hardware validation, where >>> you prototype an IP and instantiate its drivers and test it. >>> >>> Was there a strong reason to integrate QoS features directly in stmmac and not >>> in synopsys/dwc_eth_qos.*? >> >> We decided to enhance the stmmac on supporting the QoS for several >> reasons; for example the common APIs that the driver already exposed and >> actually suitable for other SYNP chips. Then, PTP, EEE, >> S/RGMII, MMC could be shared among different chips with a minimal >> effort. This meant a lot of code already ready. >> >> For sure, the net-core, Ethtool, mdio parts were reused. Same for the >> glue logic files. >> For the latter, this helped to easily bring-up new platforms also >> because the stmmac uses the HW cap register to auto-configure many >> parts of the MAC core, DMA and modules. This helped many users, AFAIK. >> >> For validation purpose, this is my experience, the stmmac helped >> a lot because people used the same code to validate different HW >> and it was easy to switch to a platform to another one in order to >> verify / check if the support was ok or if a regression was introduced. >> This is important for complex supports like PTP or EEE. >> >> Hoping this can help. >> >> Do not hesitate to contact me for further details > > Thanks for the highly detailed info. > My target application is to prototype the Ethernet QoS IP in a FPGA, with a PHY > attached and make hardware validation. > > In your opinion a refactored stmmac with the missing QoS features would be > suitable for it? I think so; somebody also added code for FPGA. In any case, step-by-step we can explore and understand how to proceed. I wonder if you could start looking at the internal of the stmmac. Then welcome doubts and open question... > > Thanks. welcome peppe > >> >> peppe > >