On Fri, 2009-11-20 at 14:29 +0100, ext Steven Fischer wrote: > > > On Fri, Nov 20, 2009 at 5:40 AM, Tomi Valkeinen > <tomi.valkeinen@xxxxxxxxx> wrote: > Just out of interest, may I ask why you are not using omapfb? > Are you > using V4L2 driver from TI? > > > For the graphic plane, we don't use the "omapfb" code as an > optimization. We have a shorter path which is being used. For the > video planes, we have a V4L2 overlay driver we wrote. It is based on > the V4L2 driver from TI, but we found the TI driver had some gaps, so > we wrote our own. You can configure omapfb to use only one framebuffer. Was there some spesific part in omapfb that was too slow? I'd be happy to get it optimized. > Given that the DSS2 exposes all three planes and knowing that there is > at least two expected input paths, omapfb and the TI V4L2 driver, how > is one expected to use the DSS2? Are you suggesting that omapfb or > V4L2 be used exclusively, not in combination? No, I'm not suggesting that. This is a known problem, but it can't be solved inside the kernel. Optimally all the changes to overlays are done first, then one update is issued. But if the overlays are handled by different entities, there's no synchronization point and the entities compete about the display. And the kernel driver cannot know what is going to happen next, so it cannot wait for the next entity to issue update, before actually starting the update. I don't know how it should be handled with V4L2, but the same problem is with omapfb. One entity is drawing to fb0, and some other entity draws to fb1. The only solution I see is that there's one control point between the kernel and the drawing-entities, and in our case this is X server (I think). The X server has a better understanding of what is going on, and can do updates better. > So how double buffering is supposed to be done is: > > 1) Fill frame A > 2) Setup overlay for A > 3) Wait until Frame B is done, with sync() > 4) Start sending frame A, with update() > 5) Fill frame B > 6) Setup overlay for B > 7) sync() > 8) update() > 9) Go back to 1 > > When you say "Setup overlay" I assume you mean both > "overlay->set_overlay_info()" and "manager->apply()", correct? Yes, I think apply is needed also. > > We have been calling sync after calling update as a means of > determining that the previous buffer is free. In your example, sync > is called, I assume, to ensure the previous update is complete before > calling update again. I need to consider this to see if this helps or > hinders our cause. If you call sync after update, you'll wait for that update to finish. Which is not what you want. So yes, the idea is to start the update for the front buffer, modify the back buffer, and when back buffer is ready, use sync to make sure that the previous transfer has been finished. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
