include/fsl-mc/fsl_qbman_base.h

1 /* SPDX-License-Identifier: GPL-2.0+ */
10  * control this QBMan instance, these values may simply be place-holders. The
16 	int irq_nrerr; /* Non-recoverable error interrupt line */
20  * the user context. Ie. on MC, this information is likely to be true-physical,
21  * and instantiated statically at compile-time. On GPP, this information is
27 	void *cena_bar; /* Cache-enabled portal register map */
28 	void *cinh_bar; /* Cache-inhibited portal register map */
34 /* Place-holder for FDs, we represent it via the simplest form that we need for
37  * routines (lots of read-modify-writes) would be worst-case performance whether
40  * Note, as with all data-structures exchanged between software and hardware (be
41  * they located in the portal register map or DMA'd to and from main-memory),
42  * the driver ensures that the caller of the driver API sees the data-structures
43  * in host-endianness. "struct qbman_fd" is no exception. The 32-bit words
44  * contained within this structure are represented in host-endianness, even if
45  * hardware always treats them as little-endian. As such, if any of these fields
53  * sequence of bytes 0xfe, 0xed, 0xab, and 0xba. So "frc" should be the 32-bit
55  * hardware is little-endian, this amounts to a 32-bit "value" of 0xbaabedfe. If
56  * the software is little-endian also, this can simply be achieved by setting
57  * frc=0xbaabedfe. On the other hand, if software is big-endian, it should set
59  * to treat the 32-bit words as numerical values, in which the offset of a field
61  * is numerically encoded by a left-shift (ie. by raising the field to a
63  * "frc" in the following way, and it would work correctly on both little-endian
64  * and big-endian operation;
74 			/* offset in the MS 16 bits, BPID in the LS 16 bits */