drivers/cdx/controller/mc_cdx_pcol.h

Source file repositories/reference/linux-study-clean/drivers/cdx/controller/mc_cdx_pcol.h

File Facts

System
Linux kernel
Corpus path
drivers/cdx/controller/mc_cdx_pcol.h
Extension
.h
Size
31701 bytes
Lines
709
Domain
Driver Families
Bucket
drivers/cdx
Inferred role
Driver Families: implementation source
Status
source implementation candidate

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

#ifndef MC_CDX_PCOL_H
#define MC_CDX_PCOL_H

/* The current version of the MCDI protocol. */
#define MCDI_PCOL_VERSION		2

/*
 * Each MCDI request starts with an MCDI_HEADER, which is a 32bit
 * structure, filled in by the client.
 *
 *       0       7  8     16    20     22  23  24    31
 *      | CODE | R | LEN | SEQ | Rsvd | E | R | XFLAGS |
 *               |                      |   |
 *               |                      |   \--- Response
 *               |                      \------- Error
 *               \------------------------------ Resync (always set)
 *
 * The client writes its request into MC shared memory, and rings the
 * doorbell. Each request is completed either by the MC writing
 * back into shared memory, or by writing out an event.
 *
 * All MCDI commands support completion by shared memory response. Each
 * request may also contain additional data (accounted for by HEADER.LEN),
 * and some responses may also contain additional data (again, accounted
 * for by HEADER.LEN).
 *
 * Some MCDI commands support completion by event, in which any associated
 * response data is included in the event.
 *
 * The protocol requires one response to be delivered for every request; a
 * request should not be sent unless the response for the previous request
 * has been received (either by polling shared memory, or by receiving
 * an event).
 */

/** Request/Response structure */
#define MCDI_HEADER_OFST		0
#define MCDI_HEADER_CODE_LBN		0
#define MCDI_HEADER_CODE_WIDTH		7
#define MCDI_HEADER_RESYNC_LBN		7
#define MCDI_HEADER_RESYNC_WIDTH	1
#define MCDI_HEADER_DATALEN_LBN		8
#define MCDI_HEADER_DATALEN_WIDTH	8
#define MCDI_HEADER_SEQ_LBN		16
#define MCDI_HEADER_SEQ_WIDTH		4
#define MCDI_HEADER_RSVD_LBN		20
#define MCDI_HEADER_RSVD_WIDTH		1
#define MCDI_HEADER_NOT_EPOCH_LBN	21
#define MCDI_HEADER_NOT_EPOCH_WIDTH	1
#define MCDI_HEADER_ERROR_LBN		22
#define MCDI_HEADER_ERROR_WIDTH		1
#define MCDI_HEADER_RESPONSE_LBN	23
#define MCDI_HEADER_RESPONSE_WIDTH	1
#define MCDI_HEADER_XFLAGS_LBN		24
#define MCDI_HEADER_XFLAGS_WIDTH	8
/* Request response using event */
#define MCDI_HEADER_XFLAGS_EVREQ	0x01
/* Request (and signal) early doorbell return */
#define MCDI_HEADER_XFLAGS_DBRET	0x02

/* Maximum number of payload bytes */
#define MCDI_CTL_SDU_LEN_MAX_V2		0x400

#define MCDI_CTL_SDU_LEN_MAX MCDI_CTL_SDU_LEN_MAX_V2

/*
 * The MC can generate events for two reasons:
 *   - To advance a shared memory request if XFLAGS_EVREQ was set
 *   - As a notification (link state, i2c event), controlled
 *     via MC_CMD_LOG_CTRL
 *
 * Both events share a common structure:
 *
 *  0      32     33      36    44     52     60
 * | Data | Cont | Level | Src | Code | Rsvd |
 *           |
 *           \ There is another event pending in this notification
 *
 * If Code==CMDDONE, then the fields are further interpreted as:
 *
 *   - LEVEL==INFO    Command succeeded
 *   - LEVEL==ERR     Command failed
 *
 *    0     8         16      24     32
 *   | Seq | Datalen | Errno | Rsvd |
 *
 *   These fields are taken directly out of the standard MCDI header, i.e.,
 *   LEVEL==ERR, Datalen == 0 => Reboot
 *
 * Events can be squirted out of the UART (using LOG_CTRL) without a

Annotation

Implementation Notes