Re: Multiple hardware locks

[Eric A. <et...@lc...>]

On Sun, 2004-10-31 at 13:18, Thomas Hellstr=F6m wrote:
> Keith Whitwell wrote:
>=20
> > Thomas Hellstr=F6m wrote:
> >
> >> Hi, list!
> >>
> >> With display cards that have more and more hardware on them,=20
> >> (TV-capture, mpeg decoders) etc. that can work independently of=20
> >> oneanother, but share the same DMA engine I've find the need for more=20
> >> than one hardware lock.=20
> >
> >
> > The first question is - have you found that lock contention is=20
> > actually a problem?
> >
> >> I've done a simple implementation for the mpeg decoder of the via=20
> >> driver, but that one doesn't cover the DMA case. The question arises=20
> >> "Why should I need to wait for DMA quiescent to check whether the=20
> >> decoder is done with a frame, if there is no decoder data in any of=20
> >> the pending DMA buffers"?
> >
> >
> > But this question isn't really answered by having multiple locks - it=20
> > sounds more like you want some sort of IRQ notification or=20
> > timestamping mechanism. Under normal circumstances grabbing the lock=20
> > doesn't mean waiting for DMA quiescence.
> >
> The typical case here:
>=20
> I want a DRI client to flip a video frame to screen, using a hardware=20
> entity called the HQV. This is a rather time critical operation. To do=20
> this I have to take the hardware lock.
>=20
> While this is happening, another thread is waiting for the mpeg decoder=20
> to complete a frame. To to that, this thread needs to take the hardware=20
> lock, wait for quiescent DMA, and then wait for the mpeg decoder to=20
> signal idle. It might be that the DMA command queue does not even=20
> contain mpeg data. This waiting delays the frame flip enough to create a=20
> visible jump in the video.
>=20
> With multiple locks:
>=20
> The first thread checks the HQV lock, it is available and frame flipping=20
> is done immediately.
>=20
> The other thread meanwhile takes the MPEG engine lock, waits until the=20
> DMA engine has processed all MPEG commands in the command queue and then=20
> waits for the MPEG engine to be idle. DMA might still be processing 3D=20
> commands.

Do you not have interrupts that either signal MPEG engine idle, or just
sw interrupts you can drop in the command stream?  That would let you
sleep waiting for them (rather than spinning, a win in itself) and you
wouldn't have to hold the hardware lock.

--=20
Eric Anholt                                et...@lc...         =20
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org