On Thu, Feb 25, 2016 at 1:55 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > > On 24/02/16 22:31, Rob Clark wrote: >> On Wed, Feb 24, 2016 at 11:48 AM, Jyri Sarha <jsarha@xxxxxx> wrote: >>> From: Tomi Valkeinen <tomi.valkeinen@xxxxxx> >>> >>> 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 > > Yes. > >> 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" > issue. ahh, gotcha, I should have looked at the complete patchset BR, -R > Tomi > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
