drivers/staging/comedi/drivers/jr3_pci.h

   1 /* SPDX-License-Identifier: GPL-2.0 */
   2 /*
   3  * Helper types to take care of the fact that the DSP card memory
   4  * is 16 bits, but aligned on a 32 bit PCI boundary
   5  */
   6
   7 static inline u16 get_u16(const u32 __iomem *p)
   8 {
   9         return (u16)readl(p);
  10 }
  11
  12 static inline void set_u16(u32 __iomem *p, u16 val)
  13 {
  14         writel(val, p);
  15 }
  16
  17 static inline s16 get_s16(const s32 __iomem *p)
  18 {
  19         return (s16)readl(p);
  20 }
  21
  22 static inline void set_s16(s32 __iomem *p, s16 val)
  23 {
  24         writel(val, p);
  25 }
  26
  27 /*
  28  * The raw data is stored in a format which facilitates rapid
  29  * processing by the JR3 DSP chip. The raw_channel structure shows the
  30  * format for a single channel of data. Each channel takes four,
  31  * two-byte words.
  32  *
  33  * Raw_time is an unsigned integer which shows the value of the JR3
  34  * DSP's internal clock at the time the sample was received. The clock
  35  * runs at 1/10 the JR3 DSP cycle time. JR3's slowest DSP runs at 10
  36  * Mhz. At 10 Mhz raw_time would therefore clock at 1 Mhz.
  37  *
  38  * Raw_data is the raw data received directly from the sensor. The
  39  * sensor data stream is capable of representing 16 different
  40  * channels. Channel 0 shows the excitation voltage at the sensor. It
  41  * is used to regulate the voltage over various cable lengths.
  42  * Channels 1-6 contain the coupled force data Fx through Mz. Channel
  43  * 7 contains the sensor's calibration data. The use of channels 8-15
  44  * varies with different sensors.
  45  */
  46
  47 struct raw_channel {
  48         u32 raw_time;
  49         s32 raw_data;
  50         s32 reserved[2];
  51 };
  52
  53 /*
  54  * The force_array structure shows the layout for the decoupled and
  55  * filtered force data.
  56  */
  57 struct force_array {
  58         s32 fx;
  59         s32 fy;
  60         s32 fz;
  61         s32 mx;
  62         s32 my;
  63         s32 mz;
  64         s32 v1;
  65         s32 v2;
  66 };
  67
  68 /*
  69  * The six_axis_array structure shows the layout for the offsets and
  70  * the full scales.
  71  */
  72 struct six_axis_array {
  73         s32 fx;
  74         s32 fy;
  75         s32 fz;
  76         s32 mx;
  77         s32 my;
  78         s32 mz;
  79 };
  80
  81 /* VECT_BITS */
  82 /*
  83  * The vect_bits structure shows the layout for indicating
  84  * which axes to use in computing the vectors. Each bit signifies
  85  * selection of a single axis. The V1x axis bit corresponds to a hex
  86  * value of 0x0001 and the V2z bit corresponds to a hex value of
  87  * 0x0020. Example: to specify the axes V1x, V1y, V2x, and V2z the
  88  * pattern would be 0x002b. Vector 1 defaults to a force vector and
  89  * vector 2 defaults to a moment vector. It is possible to change one
  90  * or the other so that two force vectors or two moment vectors are
  91  * calculated. Setting the changeV1 bit or the changeV2 bit will
  92  * change that vector to be the opposite of its default. Therefore to
  93  * have two force vectors, set changeV1 to 1.
  94  */
  95
  96 /* vect_bits appears to be unused at this time */
  97 enum {
  98         fx = 0x0001,
  99         fy = 0x0002,
 100         fz = 0x0004,
 101         mx = 0x0008,
 102         my = 0x0010,
 103         mz = 0x0020,
 104         changeV2 = 0x0040,
 105         changeV1 = 0x0080
 106 };
 107
 108 /* WARNING_BITS */
 109 /*
 110  * The warning_bits structure shows the bit pattern for the warning
 111  * word. The bit fields are shown from bit 0 (lsb) to bit 15 (msb).
 112  */
 113
 114 /* XX_NEAR_SET */
 115 /*
 116  * The xx_near_sat bits signify that the indicated axis has reached or
 117  * exceeded the near saturation value.
 118  */
 119
 120 enum {
 121         fx_near_sat = 0x0001,
 122         fy_near_sat = 0x0002,
 123         fz_near_sat = 0x0004,
 124         mx_near_sat = 0x0008,
 125         my_near_sat = 0x0010,
 126         mz_near_sat = 0x0020
 127 };
 128
 129 /* ERROR_BITS */
 130 /* XX_SAT */
 131 /* MEMORY_ERROR */
 132 /* SENSOR_CHANGE */
 133
 134 /*
 135  * The error_bits structure shows the bit pattern for the error word.
 136  * The bit fields are shown from bit 0 (lsb) to bit 15 (msb). The
 137  * xx_sat bits signify that the indicated axis has reached or exceeded
 138  * the saturation value. The memory_error bit indicates that a problem
 139  * was detected in the on-board RAM during the power-up
 140  * initialization. The sensor_change bit indicates that a sensor other
 141  * than the one originally plugged in has passed its CRC check. This
 142  * bit latches, and must be reset by the user.
 143  *
 144  */
 145
 146 /* SYSTEM_BUSY */
 147
 148 /*
 149  * The system_busy bit indicates that the JR3 DSP is currently busy
 150  * and is not calculating force data. This occurs when a new
 151  * coordinate transformation, or new sensor full scale is set by the
 152  * user. A very fast system using the force data for feedback might
 153  * become unstable during the approximately 4 ms needed to accomplish
 154  * these calculations. This bit will also become active when a new
 155  * sensor is plugged in and the system needs to recalculate the
 156  * calibration CRC.
 157  */
 158
 159 /* CAL_CRC_BAD */
 160
 161 /*
 162  * The cal_crc_bad bit indicates that the calibration CRC has not
 163  * calculated to zero. CRC is short for cyclic redundancy code. It is
 164  * a method for determining the integrity of messages in data
 165  * communication. The calibration data stored inside the sensor is
 166  * transmitted to the JR3 DSP along with the sensor data. The
 167  * calibration data has a CRC attached to the end of it, to assist in
 168  * determining the completeness and integrity of the calibration data
 169  * received from the sensor. There are two reasons the CRC may not
 170  * have calculated to zero. The first is that all the calibration data
 171  * has not yet been received, the second is that the calibration data
 172  * has been corrupted. A typical sensor transmits the entire contents
 173  * of its calibration matrix over 30 times a second. Therefore, if
 174  * this bit is not zero within a couple of seconds after the sensor
 175  * has been plugged in, there is a problem with the sensor's
 176  * calibration data.
 177  */
 178
 179 /* WATCH_DOG */
 180 /* WATCH_DOG2 */
 181
 182 /*
 183  * The watch_dog and watch_dog2 bits are sensor, not processor, watch
 184  * dog bits. Watch_dog indicates that the sensor data line seems to be
 185  * acting correctly, while watch_dog2 indicates that sensor data and
 186  * clock are being received. It is possible for watch_dog2 to go off
 187  * while watch_dog does not. This would indicate an improper clock
 188  * signal, while data is acting correctly. If either watch dog barks,
 189  * the sensor data is not being received correctly.
 190  */
 191
 192 enum error_bits_t {
 193         fx_sat = 0x0001,
 194         fy_sat = 0x0002,
 195         fz_sat = 0x0004,
 196         mx_sat = 0x0008,
 197         my_sat = 0x0010,
 198         mz_sat = 0x0020,
 199         memory_error = 0x0400,
 200         sensor_change = 0x0800,
 201         system_busy = 0x1000,
 202         cal_crc_bad = 0x2000,
 203         watch_dog2 = 0x4000,
 204         watch_dog = 0x8000
 205 };
 206
 207 /* THRESH_STRUCT */
 208
 209 /*
 210  * This structure shows the layout for a single threshold packet inside of a
 211  * load envelope. Each load envelope can contain several threshold structures.
 212  * 1. data_address contains the address of the data for that threshold. This
 213  *    includes filtered, unfiltered, raw, rate, counters, error and warning data
 214  * 2. threshold is the is the value at which, if data is above or below, the
 215  *    bits will be set ... (pag.24).
 216  * 3. bit_pattern contains the bits that will be set if the threshold value is
 217  *    met or exceeded.
 218  */
 219
 220 struct thresh_struct {
 221         s32 data_address;
 222         s32 threshold;
 223         s32 bit_pattern;
 224 };
 225
 226 /* LE_STRUCT */
 227
 228 /*
 229  * Layout of a load enveloped packet. Four thresholds are showed ... for more
 230  * see manual (pag.25)
 231  * 1. latch_bits is a bit pattern that show which bits the user wants to latch.
 232  *    The latched bits will not be reset once the threshold which set them is
 233  *    no longer true. In that case the user must reset them using the reset_bit
 234  *    command.
 235  * 2. number_of_xx_thresholds specify how many GE/LE threshold there are.
 236  */
 237 struct le_struct {
 238         s32 latch_bits;
 239         s32 number_of_ge_thresholds;
 240         s32 number_of_le_thresholds;
 241         struct thresh_struct thresholds[4];
 242         s32 reserved;
 243 };
 244
 245 /* LINK_TYPES */
 246 /*
 247  * Link types is an enumerated value showing the different possible transform
 248  * link types.
 249  * 0 - end transform packet
 250  * 1 - translate along X axis (TX)
 251  * 2 - translate along Y axis (TY)
 252  * 3 - translate along Z axis (TZ)
 253  * 4 - rotate about X axis (RX)
 254  * 5 - rotate about Y axis (RY)
 255  * 6 - rotate about Z axis (RZ)
 256  * 7 - negate all axes (NEG)
 257  */
 258
 259 enum link_types {
 260         end_x_form,
 261         tx,
 262         ty,
 263         tz,
 264         rx,
 265         ry,
 266         rz,
 267         neg
 268 };
 269
 270 /* TRANSFORM */
 271 /* Structure used to describe a transform. */
 272 struct intern_transform {
 273         struct {
 274                 u32 link_type;
 275                 s32 link_amount;
 276         } link[8];
 277 };
 278
 279 /*
 280  * JR3 force/torque sensor data definition. For more information see sensor
 281  * and hardware manuals.
 282  */
 283
 284 struct jr3_sensor {
 285         /*
 286          * Raw_channels is the area used to store the raw data coming from
 287          * the sensor.
 288          */
 289
 290         struct raw_channel raw_channels[16];    /* offset 0x0000 */
 291
 292         /*
 293          * Copyright is a null terminated ASCII string containing the JR3
 294          * copyright notice.
 295          */
 296
 297         u32 copyright[0x0018];  /* offset 0x0040 */
 298         s32 reserved1[0x0008];  /* offset 0x0058 */
 299
 300         /*
 301          * Shunts contains the sensor shunt readings. Some JR3 sensors have
 302          * the ability to have their gains adjusted. This allows the
 303          * hardware full scales to be adjusted to potentially allow
 304          * better resolution or dynamic range. For sensors that have
 305          * this ability, the gain of each sensor channel is measured at
 306          * the time of calibration using a shunt resistor. The shunt
 307          * resistor is placed across one arm of the resistor bridge, and
 308          * the resulting change in the output of that channel is
 309          * measured. This measurement is called the shunt reading, and
 310          * is recorded here. If the user has changed the gain of the //
 311          * sensor, and made new shunt measurements, those shunt
 312          * measurements can be placed here. The JR3 DSP will then scale
 313          * the calibration matrix such so that the gains are again
 314          * proper for the indicated shunt readings. If shunts is 0, then
 315          * the sensor cannot have its gain changed. For details on
 316          * changing the sensor gain, and making shunts readings, please
 317          * see the sensor manual. To make these values take effect the
 318          * user must call either command (5) use transform # (pg. 33) or
 319          * command (10) set new full scales (pg. 38).
 320          */
 321
 322         struct six_axis_array shunts;           /* offset 0x0060 */
 323         s32 reserved2[2];                       /* offset 0x0066 */
 324
 325         /*
 326          * Default_FS contains the full scale that is used if the user does
 327          * not set a full scale.
 328          */
 329
 330         struct six_axis_array default_FS;       /* offset 0x0068 */
 331         s32 reserved3;                          /* offset 0x006e */
 332
 333         /*
 334          * Load_envelope_num is the load envelope number that is currently
 335          * in use. This value is set by the user after one of the load
 336          * envelopes has been initialized.
 337          */
 338
 339         s32 load_envelope_num;                  /* offset 0x006f */
 340
 341         /* Min_full_scale is the recommend minimum full scale. */
 342
 343         /*
 344          * These values in conjunction with max_full_scale (pg. 9) helps
 345          * determine the appropriate value for setting the full scales. The
 346          * software allows the user to set the sensor full scale to an
 347          * arbitrary value. But setting the full scales has some hazards. If
 348          * the full scale is set too low, the data will saturate
 349          * prematurely, and dynamic range will be lost. If the full scale is
 350          * set too high, then resolution is lost as the data is shifted to
 351          * the right and the least significant bits are lost. Therefore the
 352          * maximum full scale is the maximum value at which no resolution is
 353          * lost, and the minimum full scale is the value at which the data
 354          * will not saturate prematurely. These values are calculated
 355          * whenever a new coordinate transformation is calculated. It is
 356          * possible for the recommended maximum to be less than the
 357          * recommended minimum. This comes about primarily when using
 358          * coordinate translations. If this is the case, it means that any
 359          * full scale selection will be a compromise between dynamic range
 360          * and resolution. It is usually recommended to compromise in favor
 361          * of resolution which means that the recommend maximum full scale
 362          * should be chosen.
 363          *
 364          * WARNING: Be sure that the full scale is no less than 0.4% of the
 365          * recommended minimum full scale. Full scales below this value will
 366          * cause erroneous results.
 367          */
 368
 369         struct six_axis_array min_full_scale;   /* offset 0x0070 */
 370         s32 reserved4;                          /* offset 0x0076 */
 371
 372         /*
 373          * Transform_num is the transform number that is currently in use.
 374          * This value is set by the JR3 DSP after the user has used command
 375          * (5) use transform # (pg. 33).
 376          */
 377
 378         s32 transform_num;                      /* offset 0x0077 */
 379
 380         /*
 381          * Max_full_scale is the recommended maximum full scale.
 382          * See min_full_scale (pg. 9) for more details.
 383          */
 384
 385         struct six_axis_array max_full_scale;   /* offset 0x0078 */
 386         s32 reserved5;                          /* offset 0x007e */
 387
 388         /*
 389          * Peak_address is the address of the data which will be monitored
 390          * by the peak routine. This value is set by the user. The peak
 391          * routine will monitor any 8 contiguous addresses for peak values.
 392          * (ex. to watch filter3 data for peaks, set this value to 0x00a8).
 393          */
 394
 395         s32 peak_address;                       /* offset 0x007f */
 396
 397         /*
 398          * Full_scale is the sensor full scales which are currently in use.
 399          * Decoupled and filtered data is scaled so that +/- 16384 is equal
 400          * to the full scales. The engineering units used are indicated by
 401          * the units value discussed on page 16. The full scales for Fx, Fy,
 402          * Fz, Mx, My and Mz can be written by the user prior to calling
 403          * command (10) set new full scales (pg. 38). The full scales for V1
 404          * and V2 are set whenever the full scales are changed or when the
 405          * axes used to calculate the vectors are changed. The full scale of
 406          * V1 and V2 will always be equal to the largest full scale of the
 407          * axes used for each vector respectively.
 408          */
 409
 410         struct force_array full_scale;          /* offset 0x0080 */
 411
 412         /*
 413          * Offsets contains the sensor offsets. These values are subtracted from
 414          * the sensor data to obtain the decoupled data. The offsets are set a
 415          * few seconds (< 10) after the calibration data has been received.
 416          * They are set so that the output data will be zero. These values
 417          * can be written as well as read. The JR3 DSP will use the values
 418          * written here within 2 ms of being written. To set future
 419          * decoupled data to zero, add these values to the current decoupled
 420          * data values and place the sum here. The JR3 DSP will change these
 421          * values when a new transform is applied. So if the offsets are
 422          * such that FX is 5 and all other values are zero, after rotating
 423          * about Z by 90 degrees, FY would be 5 and all others would be zero.
 424          */
 425
 426         struct six_axis_array offsets;          /* offset 0x0088 */
 427
 428         /*
 429          * Offset_num is the number of the offset currently in use. This
 430          * value is set by the JR3 DSP after the user has executed the use
 431          * offset # command (pg. 34). It can vary between 0 and 15.
 432          */
 433
 434         s32 offset_num;                         /* offset 0x008e */
 435
 436         /*
 437          * Vect_axes is a bit map showing which of the axes are being used
 438          * in the vector calculations. This value is set by the JR3 DSP
 439          * after the user has executed the set vector axes command (pg. 37).
 440          */
 441
 442         u32 vect_axes;                          /* offset 0x008f */
 443
 444         /*
 445          * Filter0 is the decoupled, unfiltered data from the JR3 sensor.
 446          * This data has had the offsets removed.
 447          *
 448          * These force_arrays hold the filtered data. The decoupled data is
 449          * passed through cascaded low pass filters. Each succeeding filter
 450          * has a cutoff frequency of 1/4 of the preceding filter. The cutoff
 451          * frequency of filter1 is 1/16 of the sample rate from the sensor.
 452          * For a typical sensor with a sample rate of 8 kHz, the cutoff
 453          * frequency of filter1 would be 500 Hz. The following filters would
 454          * cutoff at 125 Hz, 31.25 Hz, 7.813 Hz, 1.953 Hz and 0.4883 Hz.
 455          */
 456
 457         struct force_array filter[7];           /*
 458                                                  * offset 0x0090,
 459                                                  * offset 0x0098,
 460                                                  * offset 0x00a0,
 461                                                  * offset 0x00a8,
 462                                                  * offset 0x00b0,
 463                                                  * offset 0x00b8,
 464                                                  * offset 0x00c0
 465                                                  */
 466
 467         /*
 468          * Rate_data is the calculated rate data. It is a first derivative
 469          * calculation. It is calculated at a frequency specified by the
 470          * variable rate_divisor (pg. 12). The data on which the rate is
 471          * calculated is specified by the variable rate_address (pg. 12).
 472          */
 473
 474         struct force_array rate_data;           /* offset 0x00c8 */
 475
 476         /*
 477          * Minimum_data & maximum_data are the minimum and maximum (peak)
 478          * data values. The JR3 DSP can monitor any 8 contiguous data items
 479          * for minimums and maximums at full sensor bandwidth. This area is
 480          * only updated at user request. This is done so that the user does
 481          * not miss any peaks. To read the data, use either the read peaks
 482          * command (pg. 40), or the read and reset peaks command (pg. 39).
 483          * The address of the data to watch for peaks is stored in the
 484          * variable peak_address (pg. 10). Peak data is lost when executing
 485          * a coordinate transformation or a full scale change. Peak data is
 486          * also lost when plugging in a new sensor.
 487          */
 488
 489         struct force_array minimum_data;        /* offset 0x00d0 */
 490         struct force_array maximum_data;        /* offset 0x00d8 */
 491
 492         /*
 493          * Near_sat_value & sat_value contain the value used to determine if
 494          * the raw sensor is saturated. Because of decoupling and offset
 495          * removal, it is difficult to tell from the processed data if the
 496          * sensor is saturated. These values, in conjunction with the error
 497          * and warning words (pg. 14), provide this critical information.
 498          * These two values may be set by the host processor. These values
 499          * are positive signed values, since the saturation logic uses the
 500          * absolute values of the raw data. The near_sat_value defaults to
 501          * approximately 80% of the ADC's full scale, which is 26214, while
 502          * sat_value defaults to the ADC's full scale:
 503          *
 504          *   sat_value = 32768 - 2^(16 - ADC bits)
 505          */
 506
 507         s32 near_sat_value;                     /* offset 0x00e0 */
 508         s32 sat_value;                          /* offset 0x00e1 */
 509
 510         /*
 511          * Rate_address, rate_divisor & rate_count contain the data used to
 512          * control the calculations of the rates. Rate_address is the
 513          * address of the data used for the rate calculation. The JR3 DSP
 514          * will calculate rates for any 8 contiguous values (ex. to
 515          * calculate rates for filter3 data set rate_address to 0x00a8).
 516          * Rate_divisor is how often the rate is calculated. If rate_divisor
 517          * is 1, the rates are calculated at full sensor bandwidth. If
 518          * rate_divisor is 200, rates are calculated every 200 samples.
 519          * Rate_divisor can be any value between 1 and 65536. Set
 520          * rate_divisor to 0 to calculate rates every 65536 samples.
 521          * Rate_count starts at zero and counts until it equals
 522          * rate_divisor, at which point the rates are calculated, and
 523          * rate_count is reset to 0. When setting a new rate divisor, it is
 524          * a good idea to set rate_count to one less than rate divisor. This
 525          * will minimize the time necessary to start the rate calculations.
 526          */
 527
 528         s32 rate_address;                       /* offset 0x00e2 */
 529         u32 rate_divisor;                       /* offset 0x00e3 */
 530         u32 rate_count;                         /* offset 0x00e4 */
 531
 532         /*
 533          * Command_word2 through command_word0 are the locations used to
 534          * send commands to the JR3 DSP. Their usage varies with the command
 535          * and is detailed later in the Command Definitions section (pg.
 536          * 29). In general the user places values into various memory
 537          * locations, and then places the command word into command_word0.
 538          * The JR3 DSP will process the command and place a 0 into
 539          * command_word0 to indicate successful completion. Alternatively
 540          * the JR3 DSP will place a negative number into command_word0 to
 541          * indicate an error condition. Please note the command locations
 542          * are numbered backwards. (I.E. command_word2 comes before
 543          * command_word1).
 544          */
 545
 546         s32 command_word2;                      /* offset 0x00e5 */
 547         s32 command_word1;                      /* offset 0x00e6 */
 548         s32 command_word0;                      /* offset 0x00e7 */
 549
 550         /*
 551          * Count1 through count6 are unsigned counters which are incremented
 552          * every time the matching filters are calculated. Filter1 is
 553          * calculated at the sensor data bandwidth. So this counter would
 554          * increment at 8 kHz for a typical sensor. The rest of the counters
 555          * are incremented at 1/4 the interval of the counter immediately
 556          * preceding it, so they would count at 2 kHz, 500 Hz, 125 Hz etc.
 557          * These counters can be used to wait for data. Each time the
 558          * counter changes, the corresponding data set can be sampled, and
 559          * this will insure that the user gets each sample, once, and only
 560          * once.
 561          */
 562
 563         u32 count1;                             /* offset 0x00e8 */
 564         u32 count2;                             /* offset 0x00e9 */
 565         u32 count3;                             /* offset 0x00ea */
 566         u32 count4;                             /* offset 0x00eb */
 567         u32 count5;                             /* offset 0x00ec */
 568         u32 count6;                             /* offset 0x00ed */
 569
 570         /*
 571          * Error_count is a running count of data reception errors. If this
 572          * counter is changing rapidly, it probably indicates a bad sensor
 573          * cable connection or other hardware problem. In most installations
 574          * error_count should not change at all. But it is possible in an
 575          * extremely noisy environment to experience occasional errors even
 576          * without a hardware problem. If the sensor is well grounded, this
 577          * is probably unavoidable in these environments. On the occasions
 578          * where this counter counts a bad sample, that sample is ignored.
 579          */
 580
 581         u32 error_count;                        /* offset 0x00ee */
 582
 583         /*
 584          * Count_x is a counter which is incremented every time the JR3 DSP
 585          * searches its job queues and finds nothing to do. It indicates the
 586          * amount of idle time the JR3 DSP has available. It can also be
 587          * used to determine if the JR3 DSP is alive. See the Performance
 588          * Issues section on pg. 49 for more details.
 589          */
 590
 591         u32 count_x;                            /* offset 0x00ef */
 592
 593         /*
 594          * Warnings & errors contain the warning and error bits
 595          * respectively. The format of these two words is discussed on page
 596          * 21 under the headings warnings_bits and error_bits.
 597          */
 598
 599         u32 warnings;                           /* offset 0x00f0 */
 600         u32 errors;                             /* offset 0x00f1 */
 601
 602         /*
 603          * Threshold_bits is a word containing the bits that are set by the
 604          * load envelopes. See load_envelopes (pg. 17) and thresh_struct
 605          * (pg. 23) for more details.
 606          */
 607
 608         s32 threshold_bits;                     /* offset 0x00f2 */
 609
 610         /*
 611          * Last_crc is the value that shows the actual calculated CRC. CRC
 612          * is short for cyclic redundancy code. It should be zero. See the
 613          * description for cal_crc_bad (pg. 21) for more information.
 614          */
 615
 616         s32 last_CRC;                           /* offset 0x00f3 */
 617
 618         /*
 619          * EEProm_ver_no contains the version number of the sensor EEProm.
 620          * EEProm version numbers can vary between 0 and 255.
 621          * Software_ver_no contains the software version number. Version
 622          * 3.02 would be stored as 302.
 623          */
 624
 625         s32 eeprom_ver_no;                      /* offset 0x00f4 */
 626         s32 software_ver_no;                    /* offset 0x00f5 */
 627
 628         /*
 629          * Software_day & software_year are the release date of the software
 630          * the JR3 DSP is currently running. Day is the day of the year,
 631          * with January 1 being 1, and December 31, being 365 for non leap
 632          * years.
 633          */
 634
 635         s32 software_day;                       /* offset 0x00f6 */
 636         s32 software_year;                      /* offset 0x00f7 */
 637
 638         /*
 639          * Serial_no & model_no are the two values which uniquely identify a
 640          * sensor. This model number does not directly correspond to the JR3
 641          * model number, but it will provide a unique identifier for
 642          * different sensor configurations.
 643          */
 644
 645         u32 serial_no;                          /* offset 0x00f8 */
 646         u32 model_no;                           /* offset 0x00f9 */
 647
 648         /*
 649          * Cal_day & cal_year are the sensor calibration date. Day is the
 650          * day of the year, with January 1 being 1, and December 31, being
 651          * 366 for leap years.
 652          */
 653
 654         s32 cal_day;                            /* offset 0x00fa */
 655         s32 cal_year;                           /* offset 0x00fb */
 656
 657         /*
 658          * Units is an enumerated read only value defining the engineering
 659          * units used in the sensor full scale. The meanings of particular
 660          * values are discussed in the section detailing the force_units
 661          * structure on page 22. The engineering units are setto customer
 662          * specifications during sensor manufacture and cannot be changed by
 663          * writing to Units.
 664          *
 665          * Bits contains the number of bits of resolution of the ADC
 666          * currently in use.
 667          *
 668          * Channels is a bit field showing which channels the current sensor
 669          * is capable of sending. If bit 0 is active, this sensor can send
 670          * channel 0, if bit 13 is active, this sensor can send channel 13,
 671          * etc. This bit can be active, even if the sensor is not currently
 672          * sending this channel. Some sensors are configurable as to which
 673          * channels to send, and this field only contains information on the
 674          * channels available to send, not on the current configuration. To
 675          * find which channels are currently being sent, monitor the
 676          * Raw_time fields (pg. 19) in the raw_channels array (pg. 7). If
 677          * the time is changing periodically, then that channel is being
 678          * received.
 679          */
 680
 681         u32 units;                              /* offset 0x00fc */
 682         s32 bits;                               /* offset 0x00fd */
 683         s32 channels;                           /* offset 0x00fe */
 684
 685         /*
 686          * Thickness specifies the overall thickness of the sensor from
 687          * flange to flange. The engineering units for this value are
 688          * contained in units (pg. 16). The sensor calibration is relative
 689          * to the center of the sensor. This value allows easy coordinate
 690          * transformation from the center of the sensor to either flange.
 691          */
 692
 693         s32 thickness;                          /* offset 0x00ff */
 694
 695         /*
 696          * Load_envelopes is a table containing the load envelope
 697          * descriptions. There are 16 possible load envelope slots in the
 698          * table. The slots are on 16 word boundaries and are numbered 0-15.
 699          * Each load envelope needs to start at the beginning of a slot but
 700          * need not be fully contained in that slot. That is to say that a
 701          * single load envelope can be larger than a single slot. The
 702          * software has been tested and ran satisfactorily with 50
 703          * thresholds active. A single load envelope this large would take
 704          * up 5 of the 16 slots. The load envelope data is laid out in an
 705          * order that is most efficient for the JR3 DSP. The structure is
 706          * detailed later in the section showing the definition of the
 707          * le_struct structure (pg. 23).
 708          */
 709
 710         struct le_struct load_envelopes[0x10];  /* offset 0x0100 */
 711
 712         /*
 713          * Transforms is a table containing the transform descriptions.
 714          * There are 16 possible transform slots in the table. The slots are
 715          * on 16 word boundaries and are numbered 0-15. Each transform needs
 716          * to start at the beginning of a slot but need not be fully
 717          * contained in that slot. That is to say that a single transform
 718          * can be larger than a single slot. A transform is 2 * no of links
 719          * + 1 words in length. So a single slot can contain a transform
 720          * with 7 links. Two slots can contain a transform that is 15 links.
 721          * The layout is detailed later in the section showing the
 722          * definition of the transform structure (pg. 26).
 723          */
 724
 725         struct intern_transform transforms[0x10];       /* offset 0x0200 */
 726 };
 727
 728 struct jr3_block {
 729         u32 program_lo[0x4000];         /*  0x00000 - 0x10000 */
 730         struct jr3_sensor sensor;       /*  0x10000 - 0x10c00 */
 731         char pad2[0x30000 - 0x00c00];   /*  0x10c00 - 0x40000 */
 732         u32 program_hi[0x8000];         /*  0x40000 - 0x60000 */
 733         u32 reset;                      /*  0x60000 - 0x60004 */
 734         char pad3[0x20000 - 0x00004];   /*  0x60004 - 0x80000 */
 735 };