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