Re: [RFC 0/2] Memory-to-memory media controller topology
On Sat, 2018-06-16 at 20:31 -0400, Nicolas Dufresne wrote: > Le vendredi 15 juin 2018 à 17:05 -0300, Ezequiel Garcia a écrit : > > > Will the end result have "device node name /dev/..." on both > > > entity > > > 1 > > > and 6 ? > > > > No. There is just one devnode /dev/videoX, which is accepts > > both CAPTURE and OUTPUT directions. > > My question is more ifthe dev node path will be provided somehow, > because it's not displayed in this topologyé > AFAIU, the device node associated to each media interface object can be discovered via the G_TOPOLOGY[1] ioctl. User gets the major:minor tuple, which can be used to get the node path. [1] https://linuxtv.org/downloads/v4l-dvb-apis/uapi/mediactl/media-ioc- g-topology.html
Re: [RFC 0/2] Memory-to-memory media controller topology
Le vendredi 15 juin 2018 à 17:05 -0300, Ezequiel Garcia a écrit : > > Will the end result have "device node name /dev/..." on both entity > > 1 > > and 6 ? > > No. There is just one devnode /dev/videoX, which is accepts > both CAPTURE and OUTPUT directions. My question is more ifthe dev node path will be provided somehow, because it's not displayed in this topologyé Nicolas signature.asc Description: This is a digitally signed message part
Re: [RFC 0/2] Memory-to-memory media controller topology
On Tue, 2018-06-12 at 10:42 -0400, Nicolas Dufresne wrote: > Le mardi 12 juin 2018 à 07:48 -0300, Ezequiel Garcia a écrit : > > 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] > > Will the end result have "device node name /dev/..." on both entity 1 > and 6 ? No. There is just one devnode /dev/videoX, which is accepts both CAPTURE and OUTPUT directions. > I got told that in the long run, one should be able to map a > device (/dev/mediaN) to it's nodes (/dev/video*). In a way that if we > keep going this way, all the media devices can be enumerated from > media > node rather then a mixed between media nodes and orphaned video > nodes. > Yes, that is the idea I think. For instance, for devices with multiple audio and video channels, there is currently no clean way to discover them and correlate e.g. video devices to audio devices. Not that this series help on that either :)
Re: [RFC 0/2] Memory-to-memory media controller topology
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
Re: [RFC 0/2] Memory-to-memory media controller topology
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. Regards, Hans > > * Also, a new media entity type is introduced. Memory-to-memory > devices have a multi-entity description and so can't > be simply embedded in other structs, or cast from other structs. > > 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 | 23 ++-- > drivers/media/v4l2-core/v4l2-mem2mem.c | 157 + > include/media/media-entity.h | 4 + > include/media/v4l2-dev.h | 2 + > include/media/v4l2-mem2mem.h | 5 + > include/uapi/linux/media.h | 2 + > 7 files changed, 222 insertions(+), 12 deletions(-) >
Re: [RFC 0/2] Memory-to-memory media controller topology
Le mardi 12 juin 2018 à 07:48 -0300, Ezequiel Garcia a écrit : > 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] Will the end result have "device node name /dev/..." on both entity 1 and 6 ? I got told that in the long run, one should be able to map a device (/dev/mediaN) to it's nodes (/dev/video*). In a way that if we keep going this way, all the media devices can be enumerated from media node rather then a mixed between media nodes and orphaned video nodes. > > 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. > > * Also, a new media entity type is introduced. Memory-to-memory > devices have a multi-entity description and so can't > be simply embedded in other structs, or cast from other structs. > > 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 | 23 ++-- > drivers/media/v4l2-core/v4l2-mem2mem.c | 157 > + > include/media/media-entity.h | 4 + > include/media/v4l2-dev.h | 2 + > include/media/v4l2-mem2mem.h | 5 + > include/uapi/linux/media.h | 2 + > 7 files changed, 222 insertions(+), 12 deletions(-) > > -- > 2.17.1 > > signature.asc Description: This is a digitally signed message part
[RFC 0/2] Memory-to-memory media controller topology
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. * Also, a new media entity type is introduced. Memory-to-memory devices have a multi-entity description and so can't be simply embedded in other structs, or cast from other structs. 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 | 23 ++-- drivers/media/v4l2-core/v4l2-mem2mem.c | 157 + include/media/media-entity.h | 4 + include/media/v4l2-dev.h | 2 + include/media/v4l2-mem2mem.h | 5 + include/uapi/linux/media.h | 2 + 7 files changed, 222 insertions(+), 12 deletions(-) -- 2.17.1
