2019-05-19 13:07:45 +01:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2015-12-21 02:21:25 +02:00
|
|
|
config FSL_FMAN
|
2016-01-01 14:55:24 +01:00
|
|
|
tristate "FMan support"
|
2016-12-19 22:42:46 +02:00
|
|
|
depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
|
2015-12-21 02:21:25 +02:00
|
|
|
select GENERIC_ALLOCATOR
|
net: fman: memac: Use lynx pcs driver
Although not stated in the datasheet, as far as I can tell PCS for mEMACs
is a "Lynx." By reusing the existing driver, we can remove the PCS
management code from the memac driver. This requires calling some PCS
functions manually which phylink would usually do for us, but we will let
it do that soon.
One problem is that we don't actually have a PCS for QSGMII. We pretend
that each mEMAC's MDIO bus has four QSGMII PCSs, but this is not the case.
Only the "base" mEMAC's MDIO bus has the four QSGMII PCSs. This is not an
issue yet, because we never get the PCS state. However, it will be once the
conversion to phylink is complete, since the links will appear to never
come up. To get around this, we allow specifying multiple PCSs in pcsphy.
This breaks backwards compatibility with old device trees, but only for
QSGMII. IMO this is the only reasonable way to figure out what the actual
QSGMII PCS is.
Additionally, we now also support a separate XFI PCS. This can allow the
SerDes driver to set different addresses for the SGMII and XFI PCSs so they
can be accessed at the same time.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-10-17 16:22:37 -04:00
|
|
|
select PHYLINK
|
|
|
|
select PCS_LYNX
|
2020-12-04 00:20:37 +01:00
|
|
|
select CRC32
|
2015-12-21 02:21:25 +02:00
|
|
|
default n
|
|
|
|
help
|
|
|
|
Freescale Data-Path Acceleration Architecture Frame Manager
|
|
|
|
(FMan) support
|
2020-03-04 18:04:27 +02:00
|
|
|
|
|
|
|
config DPAA_ERRATUM_A050385
|
|
|
|
bool
|
|
|
|
depends on ARM64 && FSL_DPAA
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
DPAA FMan erratum A050385 software workaround implementation:
|
|
|
|
align buffers, data start, SG fragment length to avoid FMan DMA
|
|
|
|
splits.
|
|
|
|
FMAN DMA read or writes under heavy traffic load may cause FMAN
|
|
|
|
internal resource leak thus stopping further packet processing.
|
|
|
|
The FMAN internal queue can overflow when FMAN splits single
|
|
|
|
read or write transactions into multiple smaller transactions
|
|
|
|
such that more than 17 AXI transactions are in flight from FMAN
|
|
|
|
to interconnect. When the FMAN internal queue overflows, it can
|
|
|
|
stall further packet processing. The issue can occur with any
|
|
|
|
one of the following three conditions:
|
|
|
|
1. FMAN AXI transaction crosses 4K address boundary (Errata
|
|
|
|
A010022)
|
|
|
|
2. FMAN DMA address for an AXI transaction is not 16 byte
|
|
|
|
aligned, i.e. the last 4 bits of an address are non-zero
|
|
|
|
3. Scatter Gather (SG) frames have more than one SG buffer in
|
|
|
|
the SG list and any one of the buffers, except the last
|
|
|
|
buffer in the SG list has data size that is not a multiple
|
|
|
|
of 16 bytes, i.e., other than 16, 32, 48, 64, etc.
|
|
|
|
With any one of the above three conditions present, there is
|
|
|
|
likelihood of stalled FMAN packet processing, especially under
|
|
|
|
stress with multiple ports injecting line-rate traffic.
|