Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935980AbcKWLnq (ORCPT ); Wed, 23 Nov 2016 06:43:46 -0500 Received: from smtprelay2.synopsys.com ([198.182.60.111]:58062 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753807AbcKWLnp (ORCPT ); Wed, 23 Nov 2016 06:43:45 -0500 Subject: Re: Synopsys Ethernet QoS Driver To: Lars Persson , Joao Pinto 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> <7c7798b5-8cd4-ba99-f526-22d3e06e05db@synopsys.com> <2eefdb8f-7e87-6009-6e50-c536d4b95dd6@synopsys.com> <7c259adb-5c73-f997-6b96-5be427157b08@synopsys.com> <899DC02E-84BB-489E-A1FE-5D8F3BB795B6@axis.com> CC: Giuseppe CAVALLARO , Rayagond Kokatanur , Rabin Vincent , mued dib , David Miller , Jeff Kirsher , "jiri@mellanox.com" , "saeedm@mellanox.com" , "idosch@mellanox.com" , netdev , "linux-kernel@vger.kernel.org" , "CARLOS.PALMINHA@synopsys.com" , =?UTF-8?Q?Andreas_Irest=c3=a5l?= , "alexandre.torgue@st.com" , "linux-arm-kernel@lists.infradead.org" From: Joao Pinto Message-ID: Date: Wed, 23 Nov 2016 11:43:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <899DC02E-84BB-489E-A1FE-5D8F3BB795B6@axis.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.107.19.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2921 Lines: 91 On 23-11-2016 11:41, Lars Persson wrote: > >> 23 nov. 2016 kl. 12:11 skrev Joao Pinto : >> >> Hi Peppe and Lars, >> >>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote: >>> Hello Joao, Lars. >>> >>>> On 11/22/2016 3:16 PM, Joao Pinto wrote: >>>>>> Ok, it makes sense. >>>>>> Just for curiosity the target setup is the following: >>>>>> https://www.youtube.com/watch?v=8V-LB5y2Cos >>>>>> but instead of using internal drivers, we desire to use mainline drivers only. >>>>>> >>>>>> Thanks! >>>> Regarding this subject, I am thinking of making the following adaption: >>>> >>>> a) delete ethernet/synopsys >>>> b) rename ethernet/stmicro/stmmac to ethernet/synopsys >>>> >>>> and send you a patch for you to evaluate. Both agree with the approach? >>>> To have a new work base would be important, because I will add to the "new" >>>> structure some missing QoS features like Multichannel support, CBS and later TSN. >>> >>> IMO, we have to agree on a common strategy making the change for >>> net-next; I imaged the following steps: >> >> Yes it makes totally sense. >> >>> >>> - to port missing feature or fixes from ethernet/synopsys >>> inside the stmmac taking care about the documentation too. >> >> @Lars: You are familiar with the synopsys qos driver. Could you please do this >> porting. You can also make an analysis of what to port and I can do the porting >> for you if you don't have the availability for it. > > As my main duty is changing diapers until March next year, please go ahead with this step if you can spend time on it before I am back in office. Congratulations :)! > > Rabin Vincent can review and test that the port works properly on our Artpec-chips that use dwc_eth_qos.c today. > > The main porting step is to implement the device tree binding in bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict requirement that the phy is enabled when the SWR reset bit is set (it needs a tx clock to complete the reset). > > - Lars Ok, I will do the task. @Peppe: Agree with the plan? > >> >>> - remove ethernet/synopsys >>> - rename ethernet/stmicro/stmmac to ethernet/synopsys >> >> I volunteer to do this task. >> >>> >>> These latest two have some relevant impacts. >>> >>> This change should be propagated to all the platforms that are using: >>> CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH >>> plus device-tree compatibility. >> >> I volunteer to do this task also. >> >>> >>> - enhance the stmmac with new features and new glue (part of these >>> can be anticipated for sure). >> >> I have to implement 3 new features for now, but I will take some time for it, so >> I would suggest to make the previous task and incrementally add features. >> >>> >>> what do you think? does it make sense? If yes, we can also >>> understand how/who starts. >>> >>> Regards, >>> Peppe >> >> Thanks and regards. >> >> Joao >> >>> >>>> Thanks. >>> >>