RE: Mem2Mem V4L2 devices [RFC]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Monday, October 05, 2009 10:02 PM Karicheri, Muralidharan wrote:

> There is another use case where there are two Resizer hardware working om the same input frame and
> give two different output frames of different resolution. How do we handle this using the one video
> device approach you
> just described here?

How the hardware is actually designed? I see two possibilities:

1.
[input buffer] --[dma engine]----> [resizer1] --[dma]-> [mem output buffer1]
                               \-> [resizer2] --[dma]-> [mem output buffer2]

2.
[input buffer] ---[dma engine1]-> [resizer1] --[dma]-> [mem output buffer1]
                \-[dma engine2]-> [resizer2] --[dma]-> [mem output buffer2]

In the first case we would really have problems mapping it properly to video
nodes. But we should think if there are any use cases of such design? (in
terms of mem-2-mem device) I know that this Y-type design makes sense as a
part of the pipeline from a sensor or decoder device. But I cannot find any
useful use case for mem2mem version of it.

The second case is much more trivial. One can just create two separate resizer
devices (with their own nodes) or one resizer driver with two hardware
resizers underneath it. In both cases application would simply queue the input
buffer 2 times for both transactions.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux