[PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list

[Brian Starkey]

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