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

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

 



On Fri, 2018-06-15 at 10:59 +0200, Hans Verkuil wrote:
> On 12/06/18 12:48, 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.
> > 
> > This RFC is a first draft on the memory-to-memory
> > media controller topology.
> > 
> > The topology looks like this:
> > 
> > Device topology
> > - entity 1: input (1 pad, 1 link)
> >             type Node subtype Unknown flags 0
> > 	pad0: Source
> > 		-> "proc":1 [ENABLED,IMMUTABLE]
> > 
> > - entity 3: proc (2 pads, 2 links)
> >             type Node subtype Unknown flags 0
> > 	pad0: Source
> > 		-> "output":0 [ENABLED,IMMUTABLE]
> > 	pad1: Sink
> > 		<- "input":0 [ENABLED,IMMUTABLE]
> > 
> > - entity 6: output (1 pad, 1 link)
> >             type Node subtype Unknown flags 0
> > 	pad0: Sink
> > 		<- "proc":0 [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.
> > 
> > Notes
> > -----
> > 
> > * A new device node type is introduced VFL_TYPE_MEM2MEM,
> >   this is mostly done so the video4linux core doesn't
> >   try to register other media controller entities.
> 
> There is no need for this. You can check if vfl_dir == VFL_DIR_M2M
> instead. I'd rather not add a new VFL_TYPE.
> 

OK, sounds good.

Thanks,
Eze



[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