vc4 DLIST patches #5862
Merged
vc4 DLIST patches #5862
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ve once vc4_hvs_dlist_free_work was iterating through the list of stale dlist entries and reading the frame count and active flags from the hardware for each one. Read the frame count and active flags once, and then use the cached value in the loop. Signed-off-by: Dave Stevenson <[email protected]>
This is largely for debug at present. For reasons unknown we are not getting the end of frame interrupts that should trigger a sweep of stale dlist entries. On allocation failure clear out ALL stale entries, and retry the allocation. Log the interrupt status so we have debug regarding whether the HVS believes the interrupt is enabled. Signed-off-by: Dave Stevenson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#5674 patches, although I happened to be on a 6.6 branch so they're against that.
Tested such that the EOF handler deliberately doesn't release stale allocations, and
kmstest --flipends up triggering it every 8-10 seconds, and doesn't fail.If we see the same repeat rate, then it's reasonable to hypothesize that the interrupt has either got stuck in hardware, has been disabled, or otherwise isn't firing reliably.