[PATCH v4 15/22] drm/tilcdc: Get rid of complex ping-pong mechanism
robdclark at gmail.com
Thu Feb 25 13:37:53 UTC 2016
On Thu, Feb 25, 2016 at 1:55 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 24/02/16 22:31, Rob Clark wrote:
>> On Wed, Feb 24, 2016 at 11:48 AM, Jyri Sarha <jsarha at ti.com> wrote:
>>> From: Tomi Valkeinen <tomi.valkeinen at ti.com>
>>> Get rid of complex ping-pong mechanism and replace it with simpler
>>> single buffer flipping code.
>>> The LCDC HW appears to be designed mainly static framebuffers in
>>> mind. There are two modes of operation, either static single buffer,
>>> or ping pong double buffering with two static buffers switching back
>>> and forth. Luckily the framebuffer start address is fetched only in
>>> the beginning of the frame and changing the address after that only
>>> takes effect after the next vertical blank. The page flipping code can
>>> simply write the address of the new framebuffer and the page is
>>> flipped automatically after the next vertical blank. Using the ping
>>> pong double buffering makes the flipping code way more complex and it
>>> does not provide any benefit, so it is better to switch to single
>>> buffer operation.
>>> There is still one problem in updating the framebuffer dma address on
>>> the fly. There are two registers defining the framebuffer dma area and
>>> things may break if the dma address is fetched in while the registers
>>> are are being updated.
>> Just curious, but does this mean you need to avoid writing the reg's
>> too near to vblank? (I think there are other drivers which do not
>> have double buffered registers and must do this.. but it's a pain..)
>> The ping-pong mode is super-wonky, and would be nice to get rid of..
>> but with this scheme I'm not quite sure what happens if a pageflip
>> comes in too close to vblank..
> It's the same problem with both single and double buffer (ping-pong)
> modes. The HW is designed to have a static configuration of one or two
> buffers, never changed at runtime. If you change the buffers at runtime,
> and change them exactly at the bad time during vblank when the HW starts
> using the start and end addresses, you end up with broken display.
> In other words, using the double buffering mode only adds extra
> complexity to the driver, without any benefit. In fact, with the
> double-buffering mode I think it's impossible to make the system
> reliable. The driver cannot reliably track which of those two buffers
> are currently shown on the screen, so when you do a page flip, you could
> flip the wrong buffer.
> The next patch adds some safety margin for the "page-flip near vblank"
ahh, gotcha, I should have looked at the complete patchset
More information about the dri-devel