From a2a55e518f81900ab1538656e5df8d2759ccb1fb Mon Sep 17 00:00:00 2001 From: Prabhakar Kushwaha Date: Thu, 19 Mar 2015 09:20:45 -0700 Subject: driver/fsl-mc: Add support of MC Flibs Freescale's Layerscape Management Complex (MC) provide support various objects like DPRC, DPNI, DPBP and DPIO. Where: DPRC: Place holdes for other MC objectes like DPNI, DPBP, DPIO DPBP: Management of buffer pool DPIO: Used for used to QBMan portal DPNI: Represents standard network interface These objects are used for DPAA ethernet drivers. Signed-off-by: J. German Rivera Signed-off-by: Lijun Pan Signed-off-by: Stuart Yoder Signed-off-by: Geoff Thorpe Signed-off-by: Haiying Wang Signed-off-by: Cristian Sovaiala Signed-off-by: pankaj chauhan Signed-off-by: Prabhakar Kushwaha Reviewed-by: York Sun --- include/fsl-mc/fsl_qbman_base.h | 87 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 include/fsl-mc/fsl_qbman_base.h (limited to 'include/fsl-mc/fsl_qbman_base.h') diff --git a/include/fsl-mc/fsl_qbman_base.h b/include/fsl-mc/fsl_qbman_base.h new file mode 100644 index 0000000..c92cbe1 --- /dev/null +++ b/include/fsl-mc/fsl_qbman_base.h @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2014 Freescale Semiconductor + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _FSL_QBMAN_BASE_H +#define _FSL_QBMAN_BASE_H + +/* Descriptor for a QBMan instance on the SoC. On partitions/targets that do not + * control this QBMan instance, these values may simply be place-holders. The + * idea is simply that we be able to distinguish between them, eg. so that SWP + * descriptors can identify which QBMan instance they belong to. */ +struct qbman_block_desc { + void *ccsr_reg_bar; /* CCSR register map */ + int irq_rerr; /* Recoverable error interrupt line */ + int irq_nrerr; /* Non-recoverable error interrupt line */ +}; + +/* Descriptor for a QBMan software portal, expressed in terms that make sense to + * the user context. Ie. on MC, this information is likely to be true-physical, + * and instantiated statically at compile-time. On GPP, this information is + * likely to be obtained via "discovery" over a partition's "layerscape bus" + * (ie. in response to a MC portal command), and would take into account any + * virtualisation of the GPP user's address space and/or interrupt numbering. */ +struct qbman_swp_desc { + const struct qbman_block_desc *block; /* The QBMan instance */ + void *cena_bar; /* Cache-enabled portal register map */ + void *cinh_bar; /* Cache-inhibited portal register map */ +}; + +/* Driver object for managing a QBMan portal */ +struct qbman_swp; + +/* Place-holder for FDs, we represent it via the simplest form that we need for + * now. Different overlays may be needed to support different options, etc. (It + * is impractical to define One True Struct, because the resulting encoding + * routines (lots of read-modify-writes) would be worst-case performance whether + * or not circumstances required them.) + * + * Note, as with all data-structures exchanged between software and hardware (be + * they located in the portal register map or DMA'd to and from main-memory), + * the driver ensures that the caller of the driver API sees the data-structures + * in host-endianness. "struct qbman_fd" is no exception. The 32-bit words + * contained within this structure are represented in host-endianness, even if + * hardware always treats them as little-endian. As such, if any of these fields + * are interpreted in a binary (rather than numerical) fashion by hardware + * blocks (eg. accelerators), then the user should be careful. We illustrate + * with an example; + * + * Suppose the desired behaviour of an accelerator is controlled by the "frc" + * field of the FDs that are sent to it. Suppose also that the behaviour desired + * by the user corresponds to an "frc" value which is expressed as the literal + * sequence of bytes 0xfe, 0xed, 0xab, and 0xba. So "frc" should be the 32-bit + * value in which 0xfe is the first byte and 0xba is the last byte, and as + * hardware is little-endian, this amounts to a 32-bit "value" of 0xbaabedfe. If + * the software is little-endian also, this can simply be achieved by setting + * frc=0xbaabedfe. On the other hand, if software is big-endian, it should set + * frc=0xfeedabba! The best away of avoiding trouble with this sort of thing is + * to treat the 32-bit words as numerical values, in which the offset of a field + * from the beginning of the first byte (as required or generated by hardware) + * is numerically encoded by a left-shift (ie. by raising the field to a + * corresponding power of 2). Ie. in the current example, software could set + * "frc" in the following way, and it would work correctly on both little-endian + * and big-endian operation; + * fd.frc = (0xfe << 0) | (0xed << 8) | (0xab << 16) | (0xba << 24); + */ +struct qbman_fd { + union { + uint32_t words[8]; + struct qbman_fd_simple { + uint32_t addr_lo; + uint32_t addr_hi; + uint32_t len; + /* offset in the MS 16 bits, BPID in the LS 16 bits */ + uint32_t bpid_offset; + uint32_t frc; /* frame context */ + /* "err", "va", "cbmt", "asal", [...] */ + uint32_t ctrl; + /* flow context */ + uint32_t flc_lo; + uint32_t flc_hi; + } simple; + }; +}; + +#endif /* !_FSL_QBMAN_BASE_H */ -- cgit v1.1