Re: [PATCH 0/2] Memory-to-memory media controller topology

2018-06-21 Thread Ezequiel Garcia
On Thu, 2018-06-21 at 14:07 +0200, Hans Verkuil wrote:
> On 06/20/18 21:44, Ezequiel Garcia wrote:
> > As discussed on IRC, memory-to-memory need to be modeled
> > properly in order to be supported by the media controller
> > framework, and thus to support the Request API.
> > 
> > The topology looks like this:
> > 
> > Device topology
> > - entity 1: source (1 pad, 1 link)
> > type Node subtype V4L flags 0
> > pad0: Source
> > <- "proc":0 [ENABLED,IMMUTABLE]
> > 
> > - entity 3: proc (2 pads, 2 links)
> > type Node subtype Unknown flags 0
> > pad0: Source
> > -> "source":0 [ENABLED,IMMUTABLE]
> > pad1: Sink
> > <- "sink":0 [ENABLED,IMMUTABLE]
> > 
> > - entity 6: sink (1 pad, 1 link)
> > type Node subtype V4L flags 0
> > pad0: Sink
> > -> "proc":1 [ENABLED,IMMUTABLE]
> > 
> > The first commit introduces a register/unregister API,
> > that creates/destroys all the entities and pads needed,
> > and links them.
> 
> Can you add the output of v4l2-compliance -m /dev/mediaX here as
> well?
> 

Let me post a new version of the patch, with some minor changes,
including the output of the v4l2-compliance tool.

Thanks,
Eze


Re: [PATCH 0/2] Memory-to-memory media controller topology

2018-06-21 Thread Hans Verkuil
On 06/20/18 21:44, Ezequiel Garcia wrote:
> As discussed on IRC, memory-to-memory need to be modeled
> properly in order to be supported by the media controller
> framework, and thus to support the Request API.
> 
> The topology looks like this:
> 
> Device topology
> - entity 1: source (1 pad, 1 link)
> type Node subtype V4L flags 0
>   pad0: Source
>   <- "proc":0 [ENABLED,IMMUTABLE]
> 
> - entity 3: proc (2 pads, 2 links)
> type Node subtype Unknown flags 0
>   pad0: Source
>   -> "source":0 [ENABLED,IMMUTABLE]
>   pad1: Sink
>   <- "sink":0 [ENABLED,IMMUTABLE]
> 
> - entity 6: sink (1 pad, 1 link)
> type Node subtype V4L flags 0
>   pad0: Sink
>   -> "proc":1 [ENABLED,IMMUTABLE]
> 
> The first commit introduces a register/unregister API,
> that creates/destroys all the entities and pads needed,
> and links them.

Can you add the output of v4l2-compliance -m /dev/mediaX here as well?

Thanks!

Hans

> 
> The second commit uses this API to support the vim2m driver.
> 
> Ezequiel Garcia (1):
>   media: add helpers for memory-to-memory media controller
> 
> Hans Verkuil (1):
>   vim2m: add media device
> 
>  drivers/media/platform/vim2m.c |  41 +-
>  drivers/media/v4l2-core/v4l2-dev.c |  13 +-
>  drivers/media/v4l2-core/v4l2-mem2mem.c | 176 +
>  include/media/v4l2-mem2mem.h   |   5 +
>  include/uapi/linux/media.h |   3 +
>  5 files changed, 229 insertions(+), 9 deletions(-)
> 



[PATCH 0/2] Memory-to-memory media controller topology

2018-06-20 Thread Ezequiel Garcia
As discussed on IRC, memory-to-memory need to be modeled
properly in order to be supported by the media controller
framework, and thus to support the Request API.

The topology looks like this:

Device topology
- entity 1: source (1 pad, 1 link)
type Node subtype V4L flags 0
pad0: Source
<- "proc":0 [ENABLED,IMMUTABLE]

- entity 3: proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Source
-> "source":0 [ENABLED,IMMUTABLE]
pad1: Sink
<- "sink":0 [ENABLED,IMMUTABLE]

- entity 6: sink (1 pad, 1 link)
type Node subtype V4L flags 0
pad0: Sink
-> "proc":1 [ENABLED,IMMUTABLE]

The first commit introduces a register/unregister API,
that creates/destroys all the entities and pads needed,
and links them.

The second commit uses this API to support the vim2m driver.

Ezequiel Garcia (1):
  media: add helpers for memory-to-memory media controller

Hans Verkuil (1):
  vim2m: add media device

 drivers/media/platform/vim2m.c |  41 +-
 drivers/media/v4l2-core/v4l2-dev.c |  13 +-
 drivers/media/v4l2-core/v4l2-mem2mem.c | 176 +
 include/media/v4l2-mem2mem.h   |   5 +
 include/uapi/linux/media.h |   3 +
 5 files changed, 229 insertions(+), 9 deletions(-)

-- 
2.17.1