+/* JTAG interface, can be implemented with a software or hardware fifo
+ *
+ * TAP_SD and TAP_SI are illegal end states. TAP_SD/SI as end states
+ * can be emulated by using a larger scan.
+ *
+ * Code that is relatively insensitive to the path(as long
+ * as it is JTAG compliant) taken through state machine can use
+ * endstate for jtag_add_xxx_scan(). Otherwise the pause state must be
+ * specified as end state and a subsequent jtag_add_pathmove() must
+ * be issued.
+ *
+ */
+extern void jtag_add_ir_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern int interface_jtag_add_ir_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern void jtag_add_dr_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern int interface_jtag_add_dr_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern void jtag_add_plain_ir_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern int interface_jtag_add_plain_ir_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern void jtag_add_plain_dr_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+extern int interface_jtag_add_plain_dr_scan(int num_fields, scan_field_t *fields, enum tap_state endstate);
+/* run a TAP_TLR reset. End state is TAP_TLR, regardless
+ * of start state.
+ */
+extern void jtag_add_tlr();
+extern int interface_jtag_add_tlr();
+/* Do not use jtag_add_pathmove() unless you need to, but do use it
+ * if you have to.
+ *
+ * DANGER! If the target is dependent upon a particular sequence
+ * of transitions for things to work correctly(e.g. as a workaround
+ * for an errata that contradicts the JTAG standard), then pathmove
+ * must be used, even if some jtag interfaces happen to use the
+ * desired path. Worse, the jtag interface used for testing a
+ * particular implementation, could happen to use the "desired"
+ * path when transitioning to/from end
+ * state.
+ *
+ * A list of unambigious single clock state transitions, not
+ * all drivers can support this, but it is required for e.g.
+ * XScale and Xilinx support
+ *
+ * Note! TAP_TLR must not be used in the path!
+ *
+ * Note that the first on the list must be reachable
+ * via a single transition from the current state.
+ *
+ * All drivers are required to implement jtag_add_pathmove().
+ * However, if the pathmove sequence can not be precisely
+ * executed, an interface_jtag_add_pathmove() or jtag_execute_queue()
+ * must return an error. It is legal, but not recommended, that
+ * a driver returns an error in all cases for a pathmove if it
+ * can only implement a few transitions and therefore
+ * a partial implementation of pathmove would have little practical
+ * application.
+ */
+extern void jtag_add_pathmove(int num_states, enum tap_state *path);
+extern int interface_jtag_add_pathmove(int num_states, enum tap_state *path);
+/* go to TAP_RTI, if we're not already there and cycle
+ * precisely num_cycles in the TAP_RTI after which move
+ * to the end state, if it is != TAP_RTI
+ *
+ * nb! num_cycles can be 0, in which case the fn will navigate
+ * to endstate via TAP_RTI
+ */
+extern void jtag_add_runtest(int num_cycles, enum tap_state endstate);
+extern int interface_jtag_add_runtest(int num_cycles, enum tap_state endstate);
+/* A reset of the TAP state machine can be requested.
+ *
+ * Whether tms or trst reset is used depends on the capabilities of
+ * the target and jtag interface(reset_config command configures this).
+ *
+ * srst can driver a reset of the TAP state machine and vice
+ * versa
+ *
+ * Application code may need to examine value of jtag_reset_config
+ * to determine the proper codepath
+ *
+ * DANGER! Even though srst drives trst, trst might not be connected to
+ * the interface, and it might actually be *harmful* to assert trst in this case.
+ *
+ * This is why combinations such as "reset_config srst_only srst_pulls_trst"
+ * are supported.
+ *
+ * only req_tlr_or_trst and srst can have a transition for a
+ * call as the effects of transitioning both at the "same time"
+ * are undefined, but when srst_pulls_trst or vice versa,
+ * then trst & srst *must* be asserted together.
+ */
+extern void jtag_add_reset(int req_tlr_or_trst, int srst);
+/* this drives the actual srst and trst pins. srst will always be 0
+ * if jtag_reset_config & RESET_SRST_PULLS_TRST != 0 and ditto for
+ * trst.
+ *
+ * the higher level jtag_add_reset will invoke jtag_add_tlr() if
+ * approperiate
+ */
+extern int interface_jtag_add_reset(int trst, int srst);
+extern void jtag_add_end_state(enum tap_state endstate);
+extern int interface_jtag_add_end_state(enum tap_state endstate);
+extern void jtag_add_sleep(u32 us);
+extern int interface_jtag_add_sleep(u32 us);
+
+
+
+/*
+ * For software FIFO implementations, the queued commands can be executed
+ * during this call or earlier. A sw queue might decide to push out
+ * some of the jtag_add_xxx() operations once the queue is "big enough".
+ *
+ * This fn will return an error code if any of the prior jtag_add_xxx()
+ * calls caused a failure, e.g. check failure. Note that it does not
+ * matter if the operation was executed *before* jtag_execute_queue(),
+ * jtag_execute_queue() will still return an error code.
+ *
+ * All jtag_add_xxx() calls that have in_handler!=NULL will have been
+ * executed when this fn returns, but if what has been queued only
+ * clocks data out, without reading anything back, then JTAG could
+ * be running *after* jtag_execute_queue() returns. The API does
+ * not define a way to flush a hw FIFO that runs *after*
+ * jtag_execute_queue() returns.
+ *
+ * jtag_add_xxx() commands can either be executed immediately or
+ * at some time between the jtag_add_xxx() fn call and jtag_execute_queue().
+ */