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 
get_u16(const u32 __iomem * p)7 static inline u16 get_u16(const u32 __iomem *p)
8 {
9 	return (u16)readl(p);
10 }
11 
set_u16(u32 __iomem * p,u16 val)12 static inline void set_u16(u32 __iomem *p, u16 val)
13 {
14 	writel(val, p);
15 }
16 
get_s16(const s32 __iomem * p)17 static inline s16 get_s16(const s32 __iomem *p)
18 {
19 	return (s16)readl(p);
20 }
21 
set_s16(s32 __iomem * p,s16 val)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 };
736