RE: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

[Sottek, M. J <mat...@in...>]

>> This depends. For traditional MMIO we need to sync up. For async DMA,
Ring
>> buffers, and FIFOs we don't need to sync up. That is why I have no hooks
>> for syncing. I figure drivers can call the syncing functions if they need
>> it inside their own accel functions.

>Is it the other way around, async DMA, ringbuffers, and FIFOS that will
>need the syncing?

Tony is correct. I think James got it backwards.

When you have DMA, Ring Buffers, Fifo's you don't know that the command
has happened, you only know that it went into one of the aforementioned
structures. (And actually in the case are DMA buffers you don't even know
that the DMA buffer will ever be processes, which leads to the need for
flush()  in order to keep this simple we can just make sure that doesn't
happen)

So here is the obvious problem case.

Application mmap's the framebuffer.
Application Draws some pixels into the framebuffer.
Application issues an ioctl that would lead to a blit, the command is put
 in a ring buffer but hasn't happened yet.
The application draws some more pixels (via the mmap) in a region that
 intersects the previously blitted region.
The hardware gets around to the blit command and overwrites the pixels you
  just put in the frambuffer.


This is quite likely to happen when mixing direct access with asynchronous
commands. It is also possible with synchronous commands but not as likely.
The blitter does take time to process so if you access the framebuffer
during the blit you could get mixed results. (And I hear that this can
actually hang some hardware)

-Matt