Re: [PATCH] dmaengine: apple-admac: Fix position one period ahead at period boundary

["Martin Povišer" <povik+lin@cutebit.org>]

> On 2. 11. 2026, at 10:45, Jacob Procee <sn125164@gmail.com> wrote:
> 
> On 10/30/26 08:35, Jacob Procee wrote:
>> Thanks for the ack and the extra background info. I would love to take a
>> look at a race-free version of admac_cyclic_read_residue() as a separate
>> follow-up patch; v2 of this fix follows shortly.
> Hello Martin,
> 
> I looked into this using REG_DESC_RING. It only contains descriptors
> that the hardware hasn't fetched yet, and its read slot is effectively
> the hardware's fetch pointer.
> 
> Unfortunately, it isn't updated atomically with the residue reload
> either. Across 1.49 M reads, I hit 126 period boundaries. In 4 cases,
> DESC_RING still showed the old state even though the residue had already
> reloaded. In another case, DESC_RING had advanced while the residue was
> still 0 and no report had been posted. So I don't see a way to get a
> consistent, retry-free read from these registers.
> 
> One could make the retry check more comprehensive by using three
> counters: outstanding = queued + playing + reported, with playing being
> 1 unless the residue is 0. This would also catch the reverse ordering,
> where the report is posted after the descriptor is loaded, which the v2
> check doesn't cover.
> 
> However, I left the debug module running overnight (10.65 h, with music
> playing through the speakers), and never observed that reverse ordering.
> There were no XRuns or backward steps. The speaker channel had 96.6 M
> reads and 15,483 boundary hits; the second channel had 29.3 M reads and
> 86 hits.
> 
> All 1,498 snapshots that failed the three-counter check were explained
> by read skew: 822 where DESC_RING was read before the fetch while the
> residue was already full, and 676 where it was read after the fetch
> while the residue was still 0. The positions returned to ALSA never
> stepped backwards.
> 
> Given that the more complicated check would only handle a case I haven't
> observed, I'd prefer to stick with the simpler v2 retry.
> 
> Unless you know something about the hardware ordering that these traces
> wouldn't show, I'd prefer to stick with the simpler v2 retry.
> 
> Kind regards,
> Jacob

Hi Jacob,

I don’t think it’s worth doing the more complicated check either. Your v2 patch looks to be good enough given the available information. Perhaps there’s a way to do the residue read race free by involving additional features of the block incl. registers the driver currently ignores but until someone discovers it I support going with your patch.

Best regards,
Martin