Merge documentation for jtag_add_statemove from source into header block.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2148 b42882b7-edfa-0310-969c-e2dbd0fdcd60

2 files changed, 25 insertions, 32 deletions

diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c
index 97f60b53..3962fb2d 100644
--- a/src/jtag/jtag.c
+++ b/src/jtag/jtag.c
@@ -2523,33 +2523,6 @@ static int handle_tms_sequence_command(struct command_context_s *cmd_ctx, char *
 	return ERROR_OK;
 }
 
-/**
- * Moves from the current state to the goal \a state. This needs
- * to be handled according to the xsvf spec, see the XSTATE command
- * description.
- *
- * From the XSVF spec, pertaining to XSTATE:
- *
- * For special states known as stable states (Test-Logic-Reset,
- * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
- * predefined TAP state paths when the starting state is a stable state
- * and when the XSTATE specifies a new stable state.  See the STATE
- * command in the [Ref 5] for the TAP state paths between stable
- * states.
- *
- * For non-stable states, XSTATE should specify a state that is only one
- * TAP state transition distance from the current TAP state to avoid
- * undefined TAP state paths. A sequence of multiple XSTATE commands can
- * be issued to transition the TAP through a specific state path.
- *
- * @note Unless @a tms_bits holds a path that agrees with [Ref 5] in *
- * above spec, then this code is not fully conformant to the xsvf spec.
- * This puts a burden on tap_get_tms_path() function from the xsvf spec.
- * If in doubt, you should confirm that that burden is being met.
- *
- * Otherwise, state must be immediately reachable in one clock cycle,
- * and does not need to be a stable state.
- */
 int jtag_add_statemove(tap_state_t goal_state)
 {
 	tap_state_t cur_state = cmd_queue_cur_state;
diff --git a/src/jtag/jtag.h b/src/jtag/jtag.h
index e9caf984..3ad12f2d 100644
--- a/src/jtag/jtag.h
+++ b/src/jtag/jtag.h
@@ -675,16 +675,36 @@ extern void jtag_add_dr_out(jtag_tap_t* tap,
 /**
  * jtag_add_statemove() moves from the current state to @a goal_state.
  *
- * This function was originally designed to handle the XSTATE command
- * from the XSVF specification.
- *
  * @param goal_state The final TAP state.
  * @return ERROR_OK on success, or an error code on failure.
+ *
+ * Moves from the current state to the goal \a state. 
+ *
+ * This needs to be handled according to the xsvf spec, see the XSTATE
+ * command description.  From the XSVF spec, pertaining to XSTATE:
+ *
+ * For special states known as stable states (Test-Logic-Reset,
+ * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
+ * predefined TAP state paths when the starting state is a stable state
+ * and when the XSTATE specifies a new stable state.  See the STATE
+ * command in the [Ref 5] for the TAP state paths between stable
+ * states.
+ *
+ * For non-stable states, XSTATE should specify a state that is only one
+ * TAP state transition distance from the current TAP state to avoid
+ * undefined TAP state paths. A sequence of multiple XSTATE commands can
+ * be issued to transition the TAP through a specific state path.
+ *
+ * @note Unless @c tms_bits holds a path that agrees with [Ref 5] in the
+ * above spec, then this code is not fully conformant to the xsvf spec.
+ * This puts a burden on tap_get_tms_path() function from the xsvf spec.
+ * If in doubt, you should confirm that that burden is being met.
+ *
+ * Otherwise, @a goal_state must be immediately reachable in one clock
+ * cycle, and does not need to be a stable state.
  */
 extern int jtag_add_statemove(tap_state_t goal_state);
 
-
-
 /// @returns the number of times the scan queue has been flushed
 int jtag_get_flush_queue_count(void);