On Wed, Mar 06, 2019 at 08:22:44PM +0200, Laurent Pinchart wrote:
[snip]
I can always queue a new one, but I have no way of telling if the newly queued list raced with the frame end interrupt.
There's another register I'm not using that contains a shadow copy of the registers list DMA address. It mirrors the address programmed by the driver when there is no DMA of the registers list in progress, and contains the address the of registers list being DMA'ed when a DMA is in progress. I don't think I can do much with it, as reading it either before or after reprogramming (to check if I can reprogram or if the reprogram has been taken into account) is racy.
When you say it mirrors the address programmed, is that latched when the update is accepted, or it will update the moment you program the address register?
I assume the latter or you would have thought of this yourself (that seems like a really strange/not-useful behaviour!). But if it is the former you could:
- In writeback start-of-frame, create a copy of the register list, disabling writeback. - Write the address of this copy to the register
If/when an atomic commit comes in before you service the next end-of-frame:
- Write the address of the new register list - Check the status register. If the "pending" bit is zero, you know you had a potential race. - Check the DMA address register. If it corresponds to the new scene, the new commit won the race, otherwise it's been delayed by a frame.
You don't happen to have a DMA engine trigger or something you could use to do the register list modification at a guaranteed time do you?
Not that I know of, unfortunately.
Are you always going to be protected by an IOMMU, preventing the writeback from trashing physical memory? If that's not the case, then the race can have pretty dire consequences.
If the IOMMU is enabled in DT, yes. It's a system-level decision.
Well, it's your driver at the end of the day. But for me, a known race-condition which would cause random memory corruption sounds like a really Bad Thing. Halving frame-rate on systems with no IOMMU seems preferable to me.
Cheers, -Brian