Closed zero9178 closed 4 months ago
LGTM. Thanks for the fix!
Thank you! Would you mind merging this for me as well? I do not have commit writes :)
LGTM. Thanks for the fix!
Thank you! Would you mind merging this for me as well? I do not have commit writes :)
Me neither unfortunately😉 @paulsc96 and @colluca are maintainers of the repository
Thanks for the contribution @zero9178 :)
Looking at the PR, it looks like this breaks the way zero-sized transfers are handled (return a transaction ID of -1).
I'm adding a test for these transfers and correcting the condition. Will merge as soon as I get this fixed :)
Thanks good catch I did not consider these. Could these use 0 instead or does the DMA engine return 0 for the very first transaction? Otherwise I'd just change the bltu
to blt
Thanks good catch I did not consider these. Could these use 0 instead or does the DMA engine return 0 for the very first transaction? Otherwise I'd just change the
bltu
toblt
Zero seems to work. But actually the new DMA should support zero-sized transfers, so removing the if condition on the size altogether should work. There seems to be a bug however which I'm currently investigating.
A fix to the DMA bug is provided in https://github.com/pulp-platform/iDMA/pull/50. Till that is merged and a new release of the iDMA is created, we can merge this PR with the zero ID as suggested.
The previous implementation of
snrt_dma_wait
was incorrect as it had an infinite loop in the case thattid
was the last completed transaction. Looking at the documentation, the snippet in custom_instructions.md shows the correct way of implementing the transaction check (get last completed tid and loop if it's less than the one we are waiting for) except it had its register operands swapped. This PR uses that implementation instead, fixes the small bug in the documentation and changes one of the waits indma_simple.c
to make sure we don't regress either.