Magnus Lundin wrote:
> Dick Hollenbeck skrev:
>> Zach,
>>
>> I think this patch is fundamentally wrong and is a disaster the
>> moment it is applied.
>>
>> The queue sits between the jtag api and the drivers. The api calls
>> track "future" state according to the most recent api call submitted
>> (and put onto the back end of the queue) via the cmd_queue_cur_state
>> variable.
>>
>> The drivers consume commands in batch mode off the back end of the
>> queue. They have their own notion of state, and that is what the
>> "cable helper API" is for. That API has that name deliberately so
>> that you know these functions are for cable drivers, not for the jtag
>> api layer. Rather than worrying about a future state, they are
>> worrying about current state of the taps as the driver actually
>> manipulates TMS and the clock.
>>
>>
> Right, but the situation where this came up is when the tap state, or
> actually the target jtag controller changes state and the drivers must
> be informed about this.
>
> We cannot use cmd_queue_cur_state for this since it only records the
> state for sanity checking.
Nonsense.
cmd_queue_cur_state is a record of "the future effect of the most
recently queued command", i.e. what was last put into the queue. The
queue can be thought of as a pipe with a delay, and the contents of the
queue should eventually find its way to the driver then to the tap
controllers. Anything in the queue cannot be undone, but is not in
effect yet. Image a piece of PVC pipe and you put billiard balls into
it of different colors. There is a delay, and then the balls come out
in the same sequence some time later.
Two observers, one at the entrance to the pipe and one at the tail of
the pipe will see the same balls, but not at the same time. The balls
are analogous to the commands.
tap_set_state() is a "reporting mechanism" by the last observer. The
driver is reporting what it did to the taps and what state the driver
believes the actual hardware taps to be in because of actions that the
driver took in response to commands coming in via the queue. Only the
driver executes commands and therefore it is the only code which knows
what it did, and how this effects the actual taps. Therefore they
should be the only ones to call tap_set_state().
If you allow anybody but a driver to call tap_set_state() you have
perverted the purpose of tap_set_state() and you have brought on
insanity, so checking for it, as you state, is not needed, because it is
sure to be present.
You can create an accessor/variable pair for the front of the queue, but
it must be separate from the cable helper api.
I would suggest
jtag_set_future_state(),
jtag_record_future_state(), or
jtag_set_requested_state()
as possible function names for this encapsulation of the global variable
that you would like to hide.
jtag_set_requested_state( aState )
{
cmd_queue_cur_state = aState
}
jtag_get_requested_state()
{
return cmd_queue_cur_state;
}
All suggestions use a prefix different from the tap_ prefix which seems
to be common among functions in the cable helper api. Seems to be,
because that is how I wrote them.
Do not confuse what you are seeing at the entrance to the pipe and the
expected consequences of commands issued there at the jtag level, with
what is actually in the tap controllers beyond the end of the pipe and
accomplished by the drivers.
Dick
>
> We can add a " jtag_add_forced_set_state" or someting similar.
>
> Or we can do a jtag_execute_queue to flush the command queue and then
> a tap_set_state().
>> These two concepts are separate, and cannot be merged because of the
>> queue. tap_set_state() is for current state of the taps. But
>> realize there is can be some delay here also because sometimes their
>> are low level commands buffered before being sent out on USB. So
>> tap_set_state() only tracks to the best of its ability the current
>> state.
>>
>>
>> Dick
>>
>>
> Best regards
> Magnus
>
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
