lkml.org 
[lkml]   [2020]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH AUTOSEL 4.14 17/28] dt-bindings: net: FMan erratum A050385
    Date
    From: Madalin Bucur <madalin.bucur@nxp.com>

    [ Upstream commit 26d5bb9e4c4b541c475751e015072eb2cbf70d15 ]

    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.

    To avoid situations that stall FMAN packet processing, all of the
    above three conditions must be avoided; therefore, configure the
    system with the following rules:

    1. Frame buffers must not span a 4KB address boundary, unless
    the frame start address is 256 byte aligned
    2. All FMAN DMA start addresses (for example, BMAN buffer
    address, FD[address] + FD[offset]) are 16B aligned
    3. SG table and buffer addresses are 16B aligned and the size
    of SG buffers are multiple of 16 bytes, except for the last
    SG buffer that can be of any size.

    Additional workaround notes:
    - Address alignment of 64 bytes is recommended for maximally
    efficient system bus transactions (although 16 byte alignment is
    sufficient to avoid the stall condition)
    - To support frame sizes that are larger than 4K bytes, there are
    two options:
    1. Large single buffer frames that span a 4KB page boundary can
    be converted into SG frames to avoid transaction splits at
    the 4KB boundary,
    2. Align the large single buffer to 256B address boundaries,
    ensure that the frame address plus offset is 256B aligned.
    - If software generated SG frames have buffers that are unaligned
    and with random non-multiple of 16 byte lengths, before
    transmitting such frames via FMAN, frames will need to be copied
    into a new single buffer or multiple buffer SG frame that is
    compliant with the three rules listed above.

    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    Documentation/devicetree/bindings/net/fsl-fman.txt | 7 +++++++
    1 file changed, 7 insertions(+)

    diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
    index df873d1f3b7c5..2aaae210317bb 100644
    --- a/Documentation/devicetree/bindings/net/fsl-fman.txt
    +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
    @@ -110,6 +110,13 @@ PROPERTIES
    Usage: required
    Definition: See soc/fsl/qman.txt and soc/fsl/bman.txt

    +- fsl,erratum-a050385
    + Usage: optional
    + Value type: boolean
    + Definition: A boolean property. Indicates the presence of the
    + erratum A050385 which indicates that DMA transactions that are
    + split can result in a FMan lock.
    +
    =============================================================================
    FMan MURAM Node

    --
    2.20.1
    \
     
     \ /
      Last update: 2020-03-18 21:58    [W:2.926 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site