[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7318c77e-3011-03f3-e673-54e3bb0554aa@st.com>
Date: Mon, 21 Nov 2016 16:03:28 +0100
From: Giuseppe CAVALLARO <peppe.cavallaro@...com>
To: Joao Pinto <Joao.Pinto@...opsys.com>,
Rayagond Kokatanur <rayagond@...avyalabs.com>,
Rabin Vincent <rabin@....in>
CC: mued dib <kreptor@...il.com>, David Miller <davem@...emloft.net>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
<jiri@...lanox.com>, <saeedm@...lanox.com>, <idosch@...lanox.com>,
netdev <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<CARLOS.PALMINHA@...opsys.com>, <andreas.irestal@...s.com>,
<alexandre.torgue@...com>, <lars.persson@...s.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: Synopsys Ethernet QoS Driver
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
>
>
Powered by blists - more mailing lists