Thread (25 messages) flat view 25 messages, 8 authors, 2016-12-07

Re: Synopsys Ethernet QoS Driver

From: Joao Pinto <hidden>
Date: 2016-11-21 13:49:01
Also in: linux-arm-kernel, lkml

Hello Peppe,

On 21-11-2016 12:52, Giuseppe CAVALLARO wrote:
Hello Joao

On 11/21/2016 1:32 PM, Joao Pinto wrote:
quoted
Hello,

On 21-11-2016 05:29, Rayagond Kokatanur wrote:
quoted
On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent [off-list ref] wrote:
quoted
On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
quoted
For now we are interesting in improving the synopsys QoS driver under
/nect/ethernet/synopsys. For now the driver structure consists of a single
file
called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
related stuff.

Our strategy would be:

a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver (dwc_eth_qos_pci.c)
c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
related stuff to be reused by the platform / pci drivers
d) Add a set of features to the "core driver" that we have available
internally
Note that there are actually two drivers in mainline for this hardware:

 drivers/net/ethernet/synopsis/
 drivers/net/ethernet/stmicro/stmmac/
Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
both 3.x and 4.x. It has glue layer for pci, platform, core etc,
please refer this driver once before you start.

You can start adding missing feature of 4.x in stmmac driver.
Thanks you all for all the info.
Well, I think we are in a good position to organize the ethernet drivers
concerning Synopsys IPs.

First of all, in my opinion, it does not make sense to have a ethernet/synopsis
(typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
vendor using the same IP it should be able to reuse the commonn operations. But
I would put that discussion for later :)

For now I suggest that for we create ethernet/qos and create there a folder
called dwc (designware controller) where all the synopsys qos IP specific code
in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
figure out a clean interface for "client drivers" like stmmac to interact with
the new qos driver.

What do you think about this approach?
The stmmac drivers run since many years on several platforms
(sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
configurations starting from 3.1x to 3.7x databooks.
Great!
It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
are fully working.
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.*?
Also the stmmac has platform, device-tree and pcie supports and
a lot of maintained glue-logic files.

It is fully documented inside the kernel tree.
Thanks for the information, I am going to check it out.
I am happy to have new enhancements from other developers.
So, on my side, if you want to spend your time on improving it on your
platforms please feel free to do it!

Concerning the stmicro/stmmac naming, these come from a really old
story and have no issue to adopt new folder/file names.
Thank you for your availability!
I am also open to merge fixes and changes from ethernet/synopsis.
I want to point you on some benchmarks made by Alex some months ago
(IIRC) that showed an stmmac winner (due to the several optimizations
analyzed and reviewed in this mailing list).

Peppe
Thanks
Joao
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help