Sorry I take back my earlier comment. I didn't check tap_set_state() and only assumed that it wraps cmd_queue_cur_state. But it doesn't and I just checked the patch on arm11 and it breaks arm11.
When arm11 queries cmd_queue_cur_state it wants to know in what state the previously queue command left the queue so that it can correctly queue up the next scan command. Michael On Sun, May 24, 2009 at 10:50 AM, Magnus Lundin <lun...@mlu.mine.nu> 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. > > 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 > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
