So, it seems this discussion has kind of stopped. I would like to improve the situation, but I’m not sure what to do next.
One option is I could submit a patch that moves the CR and SR accesses in the non-algorithm-based code. This would: * have no effect on people who use the algorithm, * make programming faster for people who don’t allocate a work area for some legitimate reason, and * make programming faster for people like me who can’t use the algorithm because it doesn’t work for us However, there is a risk that it might possibly cause WAITs where there weren’t any before if someone was already using the non-algorithm-based mechanism but at a very high clock rate that is too fast for the underlying Flash array. This seems like a bit of an obscure case though? What do you think? If I submit this patch, barring implementation issues, is it likely to be accepted, or would you reject it due to this risk? I would prefer not to submit a patch if the whole approach will be rejected anyway. Figuring out why the algorithm-based code doesn’t work is probably not an option, sadly, though I can certainly support someone else investigating if anyone wants to. It just seems like a problem that will take a lot of time to investigate, and I don’t have that much time available right now, especially not when a tiny patch to the non-algorithm-based code works so well for me. But I wouldn’t make things any worse; I would leave the algorithm-based code completely alone and, for those people for whom it works, they should be able to keep using it. I could also submit a patch to allow different parallelism levels, but I think that is a completely independent issue. -- Christopher Head
pgpfZTlKXPzwM.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
