staging: comedi: ni_mio_common: implement global pfi, rtsi routing

Implement device-global config interface for ni_mio devices.  In
particular, this patch implements:
INSN_DEVICE_CONFIG_TEST_ROUTE,
INSN_DEVICE_CONFIG_CONNECT_ROUTE,
INSN_DEVICE_CONFIG_DISCONNECT_ROUTE,
INSN_DEVICE_CONFIG_GET_ROUTES
for the ni mio devices.  This means that the new abstracted signal/terminal
names can be used to define signal routing with regards to the PFI
terminals and RTSI trigger bus lines.

This also adds ability to identify PFI and RTSI channels on the PFI and
RTSI subdevices using the new device-global names.  This does not change
the values that are set for channel output selections using the subdevice
interfaces--these still require direct register values.

Annotates and updates tables of register values to reflect this new
implementation status.
Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/staging/comedi/drivers/ni_stc.h

@@ -254,6 +254,8 @@
 #define NISTC_RTSI_TRIG_OLD_CLK_CHAN	7
 #define NISTC_RTSI_TRIG_NUM_CHAN(_m)	((_m) ? 8 : 7)
 #define NISTC_RTSI_TRIG_DIR(_c, _m)	((_m) ? BIT(8 + (_c)) : BIT(7 + (_c)))
+#define NISTC_RTSI_TRIG_DIR_SUB_SEL1	BIT(2)	/* only for M-Series */
+#define NISTC_RTSI_TRIG_DIR_SUB_SEL1_SHIFT	2	/* only for M-Series */
 #define NISTC_RTSI_TRIG_USE_CLK		BIT(1)
 #define NISTC_RTSI_TRIG_DRV_CLK		BIT(0)
 
@@ -423,6 +425,7 @@
 #define NISTC_RTSI_TRIGA_OUT_REG	79
 #define NISTC_RTSI_TRIGB_OUT_REG	80
 #define NISTC_RTSI_TRIGB_SUB_SEL1	BIT(15)	/* not for M-Series */
+#define NISTC_RTSI_TRIGB_SUB_SEL1_SHIFT	15	/* not for M-Series */
 #define NISTC_RTSI_TRIG(_c, _s)		(((_s) & 0xf) << (((_c) % 4) * 4))
 #define NISTC_RTSI_TRIG_MASK(_c)	NISTC_RTSI_TRIG((_c), 0xf)
 #define NISTC_RTSI_TRIG_TO_SRC(_c, _b)	(((_b) >> (((_c) % 4) * 4)) & 0xf)
@@ -964,6 +967,7 @@ struct ni_board_struct {
 #define NUM_GPCT			2
 
 #define NUM_PFI_OUTPUT_SELECT_REGS	6
+#define NUM_RTSI_SHARED_MUXS		(NI_RTSI_BRD(-1) - NI_RTSI_BRD(0) + 1)
 
 #define M_SERIES_EEPROM_SIZE		1024
 
@@ -1062,6 +1066,70 @@ struct ni_private {
 
 	/* device signal route tables */
 	struct ni_route_tables routing_tables;
+
+	/*
+	 * Number of clients (RTSI lines) for current RTSI MUX source.
+	 *
+	 * This allows resource management of RTSI board/shared mux lines by
+	 * marking the RTSI line that is using a particular MUX.  Currently,
+	 * these lines are only automatically allocated based on source of the
+	 * route requested.  Furthermore, the only way that this auto-allocation
+	 * and configuration works is via the globally-named ni signal/terminal
+	 * names.
+	 */
+	u8 rtsi_shared_mux_usage[NUM_RTSI_SHARED_MUXS];
+
+	/*
+	 * softcopy register for rtsi shared mux/board lines.
+	 * For e-series, the bit layout of this register is
+	 * (docs: mhddk/nieseries/ChipObjects/tSTC.{h,ipp},
+	 *        DAQ-STC, Jan 1999, 340934B-01):
+	 *   bits 0:2  --  NI_RTSI_BRD(0) source selection
+	 *   bits 3:5  --  NI_RTSI_BRD(1) source selection
+	 *   bits 6:8  --  NI_RTSI_BRD(2) source selection
+	 *   bits 9:11 --  NI_RTSI_BRD(3) source selection
+	 *   bit  12   --  NI_RTSI_BRD(0) direction, 0:input, 1:output
+	 *   bit  13   --  NI_RTSI_BRD(1) direction, 0:input, 1:output
+	 *   bit  14   --  NI_RTSI_BRD(2) direction, 0:input, 1:output
+	 *   bit  15   --  NI_RTSI_BRD(3) direction, 0:input, 1:output
+	 *   According to DAQ-STC:
+	 *     RTSI Board Interface--Configured as an input, each bidirectional
+	 *     RTSI_BRD pin can drive any of the seven RTSI_TRIGGER pins.
+	 *     RTSI_BRD<0..1> can also be driven by AI STOP and RTSI_BRD<2..3>
+	 *     can also be driven by the AI START and SCAN_IN_PROG signals.
+	 *     These pins provide a mechanism for additional board-level signals
+	 *     to be sent on or received from the RTSI bus.
+	 *   Couple of comments:
+	 *   - Neither the DAQ-STC nor the MHDDK is clear on what the direction
+	 *     of the RTSI_BRD pins actually means.  There does not appear to be
+	 *     any clear indication on what "output" would mean, since the point
+	 *     of the RTSI_BRD lines is to always drive one of the
+	 *     RTSI_TRIGGER<0..6> lines.
+	 *   - The DAQ-STC also indicates that the NI_RTSI_BRD lines can be
+	 *     driven by any of the RTSI_TRIGGER<0..6> lines.
+	 *     But, looking at valid device routes, as visually imported from
+	 *     NI-MAX, there appears to be only one family (so far) that has the
+	 *     ability to route a signal from one TRIGGER_LINE to another
+	 *     TRIGGER_LINE: the 653x family of DIO devices.
+	 *
+	 * For m-series, the bit layout of this register is
+	 * (docs: mhddk/nimseries/ChipObjects/tMSeries.{h,ipp}):
+	 *   bits  0:3  --  NI_RTSI_BRD(0) source selection
+	 *   bits  4:7  --  NI_RTSI_BRD(1) source selection
+	 *   bits  8:11 --  NI_RTSI_BRD(2) source selection
+	 *   bits 12:15 --  NI_RTSI_BRD(3) source selection
+	 *   Note:  The m-series does not have any option to change direction of
+	 *   NI_RTSI_BRD muxes.  Furthermore, there are no register values that
+	 *   indicate the ability to have TRIGGER_LINES driving the output of
+	 *   the NI_RTSI_BRD muxes.
+	 */
+	u16 rtsi_shared_mux_reg;
+
+	/*
+	 * Number of clients (RTSI lines) for current RGOUT0 path.
+	 * Stored in part of in RTSI_TRIG_DIR or RTSI_TRIGB registers
+	 */
+	u8 rgout0_usage;
 };
 
 static const struct comedi_lrange range_ni_E_ao_ext;