On Mon, Jun 10, 2013 at 9:52 AM, Jett.Zhou <jtzhou@xxxxxxxxxxx> wrote: > From: Jing Xiang <jxiang@xxxxxxxxxxx> > > There is bug when switch dma of graphic layer and video layer, it > configured opposite bit, fix it. So, overlays can be either graphics or video. overlay_is_vid() tells you which type. overlay_is_vid() makes its decision based on dmafetch_id which is undocumented and I don't understand it (and in another mail you said this is legacy configuration that is going to be removed). Ignoring my lack of understanding of the background: the patch here seems to make the code more correct. It will modify the path's underlying control register to enable graphics or video transfer depending on the overlay type. Turning a graphics overlay dmafetch ON will not stomp on the bits set by any video overlay dmafetch on the same path. Previously the logic was reversed. This codepath will not work correctly if there will ever be more than one overlay of the same type on the same path. For example, if we have two graphics overlays; 1. dmafetch_onoff(overlay1, on) - graphics transfer is now enabled in the hardware 2. dmafetch_onoff(overlay2, on) - graphics transfer was already enabled, no change 3. dmafetch_onoff(overlay2, off) - graphics transfer is now disabled in the hardware At this point overlay1 is still active in theory, but the driver has disabled graphics transfer at the hardware level. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
