[<prev] [next>] [day] [month] [year] [list]
Message-ID: <283da053-3754-ca06-70e3-a988221fc3e9@st.com>
Date: Wed, 23 Nov 2016 09:02:45 +0100
From: Giuseppe CAVALLARO <peppe.cavallaro@...com>
To: Ozgur Karatas <mueddib@...dex.com>,
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" <jiri@...lanox.com>,
"saeedm@...lanox.com" <saeedm@...lanox.com>,
"idosch@...lanox.com" <idosch@...lanox.com>,
netdev <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"CARLOS.PALMINHA@...opsys.com" <carlos.palminha@...opsys.com>,
"andreas.irestal@...s.com" <andreas.irestal@...s.com>,
"alexandre.torgue@...com" <alexandre.torgue@...com>,
"lars.persson@...s.com" <lars.persson@...s.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: Synopsys Ethernet QoS Driver
Hello Ozgur
On 11/22/2016 9:38 AM, Ozgur Karatas wrote:
> Hello all,
>
> I think, ethtool and mdio don't work because the tool's not support to "QoS", right?
>
> Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.
>
> I hope to be me always helpful.
tools work but indeed should be extended to support more for QoS.
This is another task we have to keep in mind, well spot.
Peppe
>
> Regards,
>
> Ozgur
>
> 21.11.2016, 16:38, "Giuseppe CAVALLARO" <peppe.cavallaro@...com>:
>> 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
>>
>> peppe
>
Powered by blists - more mailing lists