Greetings all!
Related to my other post on aborting a pending swap operation, I'm also seeking to clear the co-processor's command fifo.
Based on the "Coprocessor Faults" section of the programming guide, and my assumption that writing to REG_CMD_READ during co-processor execution would likely lead to state issues, I first attempted a reset similar to the recovery steps listed in the guide. This however led to large portions of the screen not being displayed correctly. Assuming that I was trying to feed the FIFO too early in the co-processor's initialization following reset, I had inserted delays following the reset as a test, but saw no change in observed behavior.
What appears to work reliably is simply copying the contents of REG_CMD_WRITE to REG_CMD_READ. Upon doing this, I am seeing the INT_CMDEMPTY interrupt asserted, and correct 0xFFC reported by REG_CMDB_SPACE. I'm skeptical that this is the safest way to proceed, but have otherwise been unable to use REG_CPURESET for this purpose.
My chief concern with clearing the fifo with the x_WRITE to x_READ copy, is what happens if the co-processor is part way through processing a multi-word command. Would it still be expecting parameters to follow? This smells like a race condition waiting to happen.
Any feedback on this approach, or suggestions on what to do instead?
** Side note regarding REG_COPRO_PATCH_PTR: I'm seeing conflicting info on properly using this register during the reset. According to the register definition, this is a 16-bit read-only register, however the matrix orbital github code is using 32-bit operations on it. During my tests, I've tried both sizes, and even omitting the patch pointer write from the reset. All 3 of these cases gave me the same result.
Many thanks!