Upstream: sun6i-dma interrupt attribution above channel 7 #40
Labels
No labels
blocked-physical
cleanup
hardware
infra
kernel
P1-critical
P2-high
P3-normal
P4-later
reliability
security
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tiagoagueda/a80#40
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while bringing up DMA on the A80, but it is not an A80 bug — which makes it, like
the
mc_smpcpu_tablefix in #27, reviewable purely on its own merits.sun6i_dma_interrupt()walks the status registers withibut indexes the channel array withjalone:Each register covers 8 channels, and
sun6i_dma_start_desc()correctly enables the interruptin register
idx / 8at offsetidx % 8. So a completion reported in register 1 — channels8 to 15 — is credited to channel
j, whose descriptor is then completed twice, andBUG_ON(tx->cookie < DMA_MIN_COOKIE)fires.It needs more than 8 channels busy at once, which is why it has survived. The A31 has
sixteen channels too.
Measured with dmatest, 4 threads on each of 53 channels, 400 iterations:
kernel BUG at drivers/dma/dmaengine.h:54within two minutes, every timeA second, weaker change in the same loop: the register count rounds down, so a controller
whose channel count is not a multiple of 8 (the H3 has 12) never reads its last status
register. Changed to
DIV_ROUND_UP. ⚠️ That half is reasoned from the code only and has notbeen seen on an H3 — it may deserve splitting out or dropping.
Blocked on finding the
Fixes:tag. The tree is a shallow clone, sogit blamestops atthe boundary commit and the introducing change cannot be named from here. That has to be
resolved from full history first.
patches/linux-dma-sun6i-irq/⚠️ Nothing has been submitted upstream. See 42-upstreaming.md.
Prepared for submission 2026-08-30
The blocker was stale
This issue says the
Fixes:tag cannot be named because the tree is a shallow clone. It isnot - 1.48 M commits reachable, no
.git/shallow. The introducing commit had simply neverbeen looked for:
the original 2014 driver commit, which is where
pchan = sdev->pchans + jcame from.Split into two patches
The issue suggested considering this and it turned out to be necessary: the single commit did
two things, and
42-upstreaming.md's own rule is one logical change per patch. They also havedifferent origins, which settles it:
0001Fixes: 555859308723(2014, original driver)0002DIV_ROUND_UPregister countFixes:tag - see below0002deliberately carries no tag. The mismatch dates from commit500fa9e76bbc("dmaengine:sun6i: Move number of pchans/vchans/request to device struct", 2017), but the change is
reasoned from the code and has never been observed - the A80 has sixteen channels, an exact
multiple, so it is unaffected. With no observed failure there is nothing to justify a stable
backport. It is last in the series so it can be dropped without disturbing
0001.Cleaned up for sending
45c13f3f9e3bin a separate worktree, so the exported patches no longercarry the eight
prerequisite-patch-idlines the old export hadcheckpatch.pl --strict: clean on both, one remaining error each, covered belowdrivers/dma/sun6i-dma.ocompilesRecipients from
get_maintainer.pl:Series is in
patches/linux-dma-sun6i-irq/; the worktree is~/a80/dma-serieson the buildhost, branch
dma-sun6i-irq.🔴 Two things left, both deliberately not done here
Signed-off-by:is missing, on purpose. It is a Developer Certificate of Origin assertionand must be the submitter's own - so
checkpatchreportsMissing Signed-off-by: line(s)onboth patches, and that is now the only thing it reports. Add it with
in the worktree, or let
b4 prep/b4 senddo it.Rebase onto the maintainer tree first.
45c13f3f9e3bis some way behind, and the tree'sonly remote is now Forgejo, so it cannot currently fetch upstream. Add
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.gitas a fetch remote beforesending. (The handler is unchanged in mainline as of that base, so the patches apply, but the
base should be current.)
And the standing rule from
42-upstreaming.md, which applies here more than anywhere: do notsend a patch you cannot fully explain and defend in review. This one is small and the
reasoning is in the commit messages, but it should be re-derived by hand before it goes.