2013/6/22 Daniel Drake <dsd@xxxxxxxxxx>:
> 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
Hi Daniel
Now for our controller and usage, we have 2 over-lay of the path,
they are graphic layer and video layer.
dmafetch_id =0 if it is graphic layer, dmafetch_id =1 if it is video layer.
The another mail mentioned is right, we plan to remove the
dmafetch_id and detect overlay_is_vid by other method.
But this patch did not include it yet, it will be included by
another patch later on.
Thanks
--
----------------------------------
Best Regards
Jett Zhou
--
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
