linux/drivers/char/ip2/i2pack.h
<<
>>
Prefs
   1/*******************************************************************************
   2*
   3*   (c) 1998 by Computone Corporation
   4*
   5********************************************************************************
   6*
   7*
   8*   PACKAGE:     Linux tty Device Driver for IntelliPort II family of multiport
   9*                serial I/O controllers.
  10*
  11*   DESCRIPTION: Definitions of the packets used to transfer data and commands
  12*                Host <--> Board. Information provided here is only applicable
  13*                when the standard loadware is active.
  14*
  15*******************************************************************************/
  16#ifndef I2PACK_H
  17#define I2PACK_H  1
  18
  19//-----------------------------------------------
  20// Revision History:
  21//
  22// 10 October 1991   MAG First draft
  23// 24 February 1992  MAG Additions for 1.4.x loadware
  24// 11 March 1992     MAG New status packets
  25//
  26//-----------------------------------------------
  27
  28//------------------------------------------------------------------------------
  29// Packet Formats:
  30//
  31// Information passes between the host and board through the FIFO in packets.
  32// These have headers which indicate the type of packet. Because the fifo data
  33// path may be 16-bits wide, the protocol is constrained such that each packet
  34// is always padded to an even byte count. (The lower-level interface routines
  35// -- i2ellis.c -- are designed to do this).
  36//
  37// The sender (be it host or board) must place some number of complete packets
  38// in the fifo, then place a message in the mailbox that packets are available.
  39// Placing such a message interrupts the "receiver" (be it board or host), who
  40// reads the mailbox message and determines that there are incoming packets
  41// ready. Since there are no partial packets, and the length of a packet is
  42// given in the header, the remainder of the packet can be read without checking
  43// for FIFO empty condition. The process is repeated, packet by packet, until
  44// the incoming FIFO is empty. Then the receiver uses the outbound mailbox to
  45// signal the board that it has read the data. Only then can the sender place
  46// additional data in the fifo.
  47//------------------------------------------------------------------------------
  48//
  49//------------------------------------------------
  50// Definition of Packet Header Area
  51//------------------------------------------------
  52//
  53// Caution: these only define header areas. In actual use the data runs off
  54// beyond the end of these structures.
  55//
  56// Since these structures are based on sequences of bytes which go to the board,
  57// there cannot be ANY padding between the elements.
  58#pragma pack(1)
  59
  60//----------------------------
  61// DATA PACKETS
  62//----------------------------
  63
  64typedef struct _i2DataHeader
  65{
  66        unsigned char i2sChannel;  /* The channel number: 0-255 */
  67
  68        // -- Bitfields are allocated LSB first --
  69
  70        // For incoming data, indicates whether this is an ordinary packet or a
  71        // special one (e.g., hot key hit).
  72        unsigned i2sId : 2 __attribute__ ((__packed__));
  73
  74        // For tagging data packets. There are flush commands which flush only data
  75        // packets bearing a particular tag. (used in implementing IntelliView and
  76        // IntelliPrint). THE TAG VALUE 0xf is RESERVED and must not be used (it has
  77        // meaning internally to the loadware).
  78        unsigned i2sTag : 4;
  79
  80        // These two bits determine the type of packet sent/received.
  81        unsigned i2sType : 2;
  82
  83        // The count of data to follow: does not include the possible additional
  84        // padding byte. MAXIMUM COUNT: 4094. The top four bits must be 0.
  85        unsigned short i2sCount;
  86
  87} i2DataHeader, *i2DataHeaderPtr;
  88
  89// Structure is immediately followed by the data, proper.
  90
  91//----------------------------
  92// NON-DATA PACKETS
  93//----------------------------
  94
  95typedef struct _i2CmdHeader
  96{
  97        unsigned char i2sChannel;       // The channel number: 0-255 (Except where noted
  98                                                                // - see below
  99
 100        // Number of bytes of commands, status or whatever to follow
 101        unsigned i2sCount : 6;
 102
 103        // These two bits determine the type of packet sent/received.
 104        unsigned i2sType : 2;
 105
 106} i2CmdHeader, *i2CmdHeaderPtr;
 107
 108// Structure is immediately followed by the applicable data.
 109
 110//---------------------------------------
 111// Flow Control Packets (Outbound)
 112//---------------------------------------
 113
 114// One type of outbound command packet is so important that the entire structure
 115// is explicitly defined here. That is the flow-control packet. This is never
 116// sent by user-level code (as would be the commands to raise/lower DTR, for
 117// example). These are only sent by the library routines in response to reading
 118// incoming data into the buffers.
 119//
 120// The parameters inside the command block are maintained in place, then the
 121// block is sent at the appropriate time.
 122
 123typedef struct _flowIn
 124{
 125        i2CmdHeader    hd;      // Channel #, count, type (see above)
 126        unsigned char  fcmd;    // The flow control command (37)
 127        unsigned short asof;    // As of byte number "asof" (LSB first!) I have room
 128                                                        // for "room" bytes
 129        unsigned short room;
 130} flowIn, *flowInPtr;
 131
 132//----------------------------------------
 133// (Incoming) Status Packets
 134//----------------------------------------
 135
 136// Incoming packets which are non-data packets are status packets. In this case,
 137// the channel number in the header is unimportant. What follows are one or more
 138// sub-packets, the first word of which consists of the channel (first or low
 139// byte) and the status indicator (second or high byte), followed by possibly
 140// more data.
 141
 142#define STAT_CTS_UP     0  /* CTS raised  (no other bytes) */
 143#define STAT_CTS_DN     1  /* CTS dropped (no other bytes) */
 144#define STAT_DCD_UP     2  /* DCD raised  (no other bytes) */
 145#define STAT_DCD_DN     3  /* DCD dropped (no other bytes) */
 146#define STAT_DSR_UP     4  /* DSR raised  (no other bytes) */
 147#define STAT_DSR_DN     5  /* DSR dropped (no other bytes) */
 148#define STAT_RI_UP      6  /* RI  raised  (no other bytes) */
 149#define STAT_RI_DN      7  /* RI  dropped (no other bytes) */
 150#define STAT_BRK_DET    8  /* BRK detect  (no other bytes) */
 151#define STAT_FLOW       9  /* Flow control(-- more: see below */
 152#define STAT_BMARK      10 /* Bookmark    (no other bytes)
 153                                                        * Bookmark is sent as a response to
 154                                                        * a command 60: request for bookmark
 155                                                        */
 156#define STAT_STATUS     11 /* Special packet: see below */
 157#define STAT_TXCNT      12 /* Special packet: see below */
 158#define STAT_RXCNT      13 /* Special packet: see below */
 159#define STAT_BOXIDS     14 /* Special packet: see below */
 160#define STAT_HWFAIL     15 /* Special packet: see below */
 161
 162#define STAT_MOD_ERROR  0xc0
 163#define STAT_MODEM      0xc0/* If status & STAT_MOD_ERROR:
 164                                                         * == STAT_MODEM, then this is a modem
 165                                                         * status packet, given in response to a
 166                                                         * CMD_DSS_NOW command.
 167                                                         * The low nibble has each data signal:
 168                                                         */
 169#define STAT_MOD_DCD    0x8
 170#define STAT_MOD_RI     0x4
 171#define STAT_MOD_DSR    0x2
 172#define STAT_MOD_CTS    0x1
 173
 174#define STAT_ERROR      0x80/* If status & STAT_MOD_ERROR
 175                                                         * == STAT_ERROR, then
 176                                                         * sort of error on the channel.
 177                                                         * The remaining seven bits indicate
 178                                                         * what sort of error it is.
 179                                                         */
 180/* The low three bits indicate parity, framing, or overrun errors */
 181
 182#define STAT_E_PARITY   4     /* Parity error */
 183#define STAT_E_FRAMING  2     /* Framing error */
 184#define STAT_E_OVERRUN  1     /* (uxart) overrun error */
 185
 186//---------------------------------------
 187// STAT_FLOW packets
 188//---------------------------------------
 189
 190typedef struct _flowStat
 191{
 192        unsigned short asof;
 193        unsigned short room;
 194}flowStat, *flowStatPtr;
 195
 196// flowStat packets are received from the board to regulate the flow of outgoing
 197// data. A local copy of this structure is also kept to track the amount of
 198// credits used and credits remaining. "room" is the amount of space in the
 199// board's buffers, "as of" having received a certain byte number. When sending
 200// data to the fifo, you must calculate how much buffer space your packet will
 201// use.  Add this to the current "asof" and subtract it from the current "room".
 202//
 203// The calculation for the board's buffer is given by CREDIT_USAGE, where size
 204// is the un-rounded count of either data characters or command characters.
 205// (Which is to say, the count rounded up, plus two).
 206
 207#define CREDIT_USAGE(size) (((size) + 3) & ~1)
 208
 209//---------------------------------------
 210// STAT_STATUS packets
 211//---------------------------------------
 212
 213typedef  struct   _debugStat
 214{
 215        unsigned char d_ccsr;
 216        unsigned char d_txinh;
 217        unsigned char d_stat1;
 218        unsigned char d_stat2;
 219} debugStat, *debugStatPtr;
 220
 221// debugStat packets are sent to the host in response to a CMD_GET_STATUS
 222// command.  Each byte is bit-mapped as described below:
 223
 224#define D_CCSR_XON      2     /* Has received XON, ready to transmit */
 225#define D_CCSR_XOFF     4     /* Has received XOFF, not transmitting */
 226#define D_CCSR_TXENAB   8     /* Transmitter is enabled */
 227#define D_CCSR_RXENAB   0x80  /* Receiver is enabled */
 228
 229#define D_TXINH_BREAK   1     /* We are sending a break */
 230#define D_TXINH_EMPTY   2     /* No data to send */
 231#define D_TXINH_SUSP    4     /* Output suspended via command 57 */
 232#define D_TXINH_CMD     8     /* We are processing an in-line command */
 233#define D_TXINH_LCD     0x10  /* LCD diagnostics are running */
 234#define D_TXINH_PAUSE   0x20  /* We are processing a PAUSE command */
 235#define D_TXINH_DCD     0x40  /* DCD is low, preventing transmission */
 236#define D_TXINH_DSR     0x80  /* DSR is low, preventing transmission */
 237
 238#define D_STAT1_TXEN    1     /* Transmit INTERRUPTS enabled */
 239#define D_STAT1_RXEN    2     /* Receiver INTERRUPTS enabled */
 240#define D_STAT1_MDEN    4     /* Modem (data set sigs) interrupts enabled */
 241#define D_STAT1_RLM     8     /* Remote loopback mode selected */
 242#define D_STAT1_LLM     0x10  /* Local internal loopback mode selected */
 243#define D_STAT1_CTS     0x20  /* CTS is low, preventing transmission */
 244#define D_STAT1_DTR     0x40  /* DTR is low, to stop remote transmission */
 245#define D_STAT1_RTS     0x80  /* RTS is low, to stop remote transmission */
 246
 247#define D_STAT2_TXMT    1     /* Transmit buffers are all empty */
 248#define D_STAT2_RXMT    2     /* Receive buffers are all empty */
 249#define D_STAT2_RXINH   4     /* Loadware has tried to inhibit remote
 250                                                           * transmission:  dropped DTR, sent XOFF,
 251                                                           * whatever...
 252                                                           */
 253#define D_STAT2_RXFLO   8     /* Loadware can send no more data to host
 254                                                           * until it receives a flow-control packet
 255                                                           */
 256//-----------------------------------------
 257// STAT_TXCNT and STAT_RXCNT packets
 258//----------------------------------------
 259
 260typedef  struct   _cntStat
 261{
 262        unsigned short cs_time;    // (Assumes host is little-endian!)
 263        unsigned short cs_count;
 264} cntStat, *cntStatPtr;
 265
 266// These packets are sent in response to a CMD_GET_RXCNT or a CMD_GET_TXCNT
 267// bypass command. cs_time is a running 1 Millisecond counter which acts as a
 268// time stamp. cs_count is a running counter of data sent or received from the
 269// uxarts. (Not including data added by the chip itself, as with CRLF
 270// processing).
 271//------------------------------------------
 272// STAT_HWFAIL packets
 273//------------------------------------------
 274
 275typedef struct _failStat
 276{
 277        unsigned char fs_written;
 278        unsigned char fs_read;
 279        unsigned short fs_address;
 280} failStat, *failStatPtr;
 281
 282// This packet is sent whenever the on-board diagnostic process detects an
 283// error. At startup, this process is dormant. The host can wake it up by
 284// issuing the bypass command CMD_HW_TEST. The process runs at low priority and
 285// performs continuous hardware verification; writing data to certain on-board
 286// registers, reading it back, and comparing. If it detects an error, this
 287// packet is sent to the host, and the process goes dormant again until the host
 288// sends another CMD_HW_TEST. It then continues with the next register to be
 289// tested.
 290
 291//------------------------------------------------------------------------------
 292// Macros to deal with the headers more easily! Note that these are defined so
 293// they may be used as "left" as well as "right" expressions.
 294//------------------------------------------------------------------------------
 295
 296// Given a pointer to the packet, reference the channel number
 297//
 298#define CHANNEL_OF(pP)  ((i2DataHeaderPtr)(pP))->i2sChannel
 299
 300// Given a pointer to the packet, reference the Packet type
 301//
 302#define PTYPE_OF(pP) ((i2DataHeaderPtr)(pP))->i2sType
 303
 304// The possible types of packets
 305//
 306#define PTYPE_DATA   0  /* Host <--> Board */
 307#define PTYPE_BYPASS 1  /* Host ---> Board */
 308#define PTYPE_INLINE 2  /* Host ---> Board */
 309#define PTYPE_STATUS 2  /* Host <--- Board */
 310
 311// Given a pointer to a Data packet, reference the Tag
 312//
 313#define TAG_OF(pP) ((i2DataHeaderPtr)(pP))->i2sTag
 314
 315// Given a pointer to a Data packet, reference the data i.d.
 316//
 317#define ID_OF(pP)  ((i2DataHeaderPtr)(pP))->i2sId
 318
 319// The possible types of ID's
 320//
 321#define ID_ORDINARY_DATA   0
 322#define ID_HOT_KEY         1
 323
 324// Given a pointer to a Data packet, reference the count
 325//
 326#define DATA_COUNT_OF(pP) ((i2DataHeaderPtr)(pP))->i2sCount
 327
 328// Given a pointer to a Data packet, reference the beginning of data
 329//
 330#define DATA_OF(pP) &((unsigned char *)(pP))[4] // 4 = size of header
 331
 332// Given a pointer to a Non-Data packet, reference the count
 333//
 334#define CMD_COUNT_OF(pP) ((i2CmdHeaderPtr)(pP))->i2sCount
 335
 336#define MAX_CMD_PACK_SIZE  62 // Maximum size of such a count
 337
 338// Given a pointer to a Non-Data packet, reference the beginning of data
 339//
 340#define CMD_OF(pP) &((unsigned char *)(pP))[2]  // 2 = size of header
 341
 342//--------------------------------
 343// MailBox Bits:
 344//--------------------------------
 345
 346//--------------------------
 347// Outgoing (host to board)
 348//--------------------------
 349//
 350#define MB_OUT_STUFFED     0x80  // Host has placed output in fifo 
 351#define MB_IN_STRIPPED     0x40  // Host has read in all input from fifo 
 352
 353//--------------------------
 354// Incoming (board to host)
 355//--------------------------
 356//
 357#define MB_IN_STUFFED      0x80  // Board has placed input in fifo 
 358#define MB_OUT_STRIPPED    0x40  // Board has read all output from fifo 
 359#define MB_FATAL_ERROR     0x20  // Board has encountered a fatal error
 360
 361#pragma pack()                  // Reset padding to command-line default
 362
 363#endif      // I2PACK_H
 364
 365
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.