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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel