media-workshop July 2015

media-workshop@linuxtv.org

4 participants
8 discussions

Etherpad notes
by Mauro Carvalho Chehab 31 Jul '15

31 Jul '15

-- Cheers, Mauro Media brainstorming meeting 2015 https://etherpad.fr/p/media-brainstorming-2015 https://etherpad.mozilla.org/YoMTPHKPmf 2015-07-29--31 Hans Verkuil Mauro Chehab Antti Laakso Lars-Peter Clausen Sakari Ailus Tuukka Toivonen Laurent Pinchart Shuah Khan Morning 29th Summary: Stuff is complicated Control and data planes: http://etherealmind.com/controller-based-networks-for-data-centres/ Multiple options to express association between device nodes and entities: - Same IOCTL API as for data links, difference made between data and control links - Different IOCTL API to enumerate interfaces, with associated entities - Properties Terminology: - Entity: Functional unit, typically a hardware component or subunit in a hardware component - Pad: Data Input/Output of a entity - Link: Connection between a source pad and a sink pad - Interface: Software control access to a entity (e.g. v4l2-subdev) - Association: Mapping between interface and entity One interface can control multiple entities One entity can be controlled by multiple interfaces Afternoon 29th Summary: Things are still complicated Media interfaces - A concept of user space facing interfaces - An object of its own right (such as media entities) - At the same level than entities - Mauro's concern is that there will be lots of code duplication in the kernel Working proposal - Introduce struct media_interface as an object type alongside with entities in the kernel and in the user space - See how the patches will look like; start with V4L2 and proceed with DVB - How much will there be code duplication? - Target 4.3 at earliest, more likely 4.4 - Mauro: no patches, drivers or framework, implementing MC features merged until this is fixed (fixes are an exception) - Hans: I'll try do the work next week Userspace API Requirements: - Enumerate Entities + pads/links (exists today) - Enumerate Interfaces + entity associations (+ which interface is the default) - For entities: enumerate associated interfaces - Two application models: Entity-centric vs Interface-centric Future: - MC: 'versioning number' so apps are informed if the topology has changed. - MC: Notification events for topology changes Points to solve: - entity.type - should be renamed to reflect what's there; - How to represent DVB entities/interfaces? - DVB network interfaces? - How to represent ALSA entities? - What fields are needed for media interfaces at the public API? - changes at media-ctl userspace application Random notes - man 7 netdevice - man 7 rtnetlink - Network interface index is constant for a network device - Network interface index can be converted to name etc. by an IOCTL - IOCTL design: http://blog.ffwll.ch/2013/11/botching-up-ioctls.html - Not widely used outside DRM - Most sub-systems have their own conventions TODO: - Add graph topology version to the enumeration (and possibly other) ioctls QUESTION: SHOULD WE REDESIGN EVERYTHING, TO SUPPORT TOPOLOGY CHANGES? ========================================================================= Address for tomorrow morning, at Samsung Research UK, in ESPOO Innopoli 3, Vaisalantie 4, Espoo. Morning 30th VB2 - Presentation made by Samsung via videoconf about the scheduled changes for VB2 DVB pipelines - Presentation made by Samsung via videoconf about the pipelines: tuner 1 -> -> demux -> Video tuner 2 -> cam 1 -> demux -> Audio tuner 3 -> cam 2 -> demux -> Data -> V4L2 -> ALSA ASoC Generic DT machine driver can support around half of DT based devices Not all required data available in ACPI, so ACPI based devices typically have their own drivers DAPM does power management in ASoC much like the current omap3isp driver implementation does Walks the graph Supports large numbers of entities and cyclical graphs Contains ASoC dependencies, but the core of the algorithm is generic Stack based, iterative version in works MC has generic graph walking code as well Iterative Less concerned with performance omap3isp driver has PM code, which could be more generic Ideally we should have single implementation for graph walking and for power management Updates to ALSA and au0828 to share resources: 1. state->pads[AU8522_PAD_AUDIO_OUT].flags = MEDIA_PAD_FL_SINK; Need to be MEDIA_PAD_FL_SOURCE; 2. ALSA: to use on a non-atomic context: pcm->substream->nonatomic IRQ safe start/stop pipeline isn't necessary. Not a good idea to change graph_mutex to spinlock. I2C drivers will break. This will reduce the work and patch series v6 becomes smaller. 3. enable_source is necessary at media_device level, but find a better name 4. Write helper function to hde decoder and tuner details from ALSA 5. remove link is needed - implement - Shuah can do that as part of ALSA work 6. Managed Media Controller API - devres - change it to get reference and put reference. It isn't safe to delete media_device device resource. media_device_get() and media_device_put() Keep /dev/media device open and unplug the usb device - kernel would crash Afternoon 30th Keysign party: Mauro: F909 AE68 FC11 DF09 C175 5C00 085F 3EBD 8EE4 E115 (m.chehab(a)samsung.com and mchehab(a)osg.samsung.com) BDBC 259D BFF2 2603 F5E0 B67E 1FCD 9060 (mchehab(a)infradead.org) Shuah: 3D92 B29B F459 B8E0 8678 0FE4 0B02 44C4 0D0D 431C Lars: 5C1B A1C6 C4B6 1D76 3462 D775 E8F7 68B4 9C45 B399 Laurent: 9423 1B98 0100 EC61 9AC1 0E10 F045 C2B9 6991 256E Hans: 052C DE7B C215 053B 689F 1BCA BD2D 6148 6614 3B4C Sakari Ailus <sakari.ailus(a)iki.fi>: 270C DCD3 5B9D 7E26 C2D7 2097 BF53 AD52 308A D4EC Sakari Ailus <sakari.ailus(a)linux.intel.com>: F0D0 377A 0D4F 25A7 9238 EFE5 6D40 361B 6E28 C193 IIO - Industrial I/O - ADC, DAC, accelerometer, gyro, light sensor, pressure, manometer - typically: low speed < 10kbaud, I2C/SPI - changes: up to 5Gbaud, separate control and data bus (LVDS, JESD204b) - can be used by multi-channel SDR Morning 31st Media controller discussion Generic graph framework in the kernel? This would require review on linux-media, and take a long time. Different requirements could pop up. Perhaps not this time. An agreement was arrived for the UAPI interface. Some adjustments will be left to happen tomorrow. What was agreed: media interfaces will be a separate graph element; links will be used to connect both entities (pads to pads) and media interfaces; PADs will use unique IDs preliminary header changes: https://etherpad.mozilla.org/QNyfP34Ee6 V4L2 applications need to know if they can capture from an input/tuner. To make that easy for them we should add a new flag to VIDIOC_ENUMINPUT and whether the tuner is in use (and/or the tuner state) through VIDIOC_G_TUNER. Allow for bidirectional pads (needed for connectors like a coax that are bidirectional using time or frequency multiplexing) TODO: Connector entities Afternoon 31st Entity types Connector, DMA engine, processing block and controller block have been proposed Whather an entity is a connector needs to be told All others can be derived from other information already in the graph? Entity functional properties Most of the properties at entity level would be used to signal capabilities that can be figured out using sub-system specific interfaces the application already uses Interfaces Agreement: interfaces do have a type Types include V4L2, ALSA, DVB etc. Sub-types are used to tell between different interface types inside the sub-system A device can be a device node, network interface or a sysfs directory G_TOPOLOGY IOCTL should not be used to convey arbitrary sysfs paths G_INTERFACE to pass information on single interface; there, a single pointer set by the user would be feasible. The struct can be the same. Finding entities Especially device specific applications often need to find an exact entity the application requires This may be a certain scaler in the graph, for instance Configuration may involve e.g. private IOCTLs only a certain sub-device implements Name is only 32 bytes at the moment In practice, external entities have used i2c bus number and i2c address as part of the name This does not scale for DT based devices where the device is uniquely identified by a string that can be very long Blocks that are a part of an ISP there's been just a name of the block without any device specific information This causes that if one has multiple such devices in the system, the name is no longer unique The entity name is not enough to uniquely find an entity in a general case In a general case it is not possible to recognise an entity Hot pluggable buses and entities that have no serial numbers or something equivalent In order to best help the user space, all the information that matters should be provided to the user Device name, such as "omap3isp resizer" Bus Serial number Sysfs name (this may not be stable as sysfs has no official API stability, but may be still better than bus in some cases) This should enable most of the use cases where entities need to be found Properties Array of properties as an IOCTL argument has the problem that the user would have to allocate enough memory for each key-value pair in the array. This is unfeasible. The original proposal of using a text based format requires parsing by the user, albeit the kernel interface would remain simple The new proposal combines the best of both: a single memory area amended with an array of properties that refer to the memory area Using strings the key type has benefits Hierarchy is possible (not with u32 for instance) Should values be always strings or should other types be accepted? Probably having other types is a good idea. Different options for arrays As part of the key: entity.0/name As part of the property: add a length field. This is convenient except for strings, where it works as well --- just count the nul characters. Properties could be seen as re-implementing sysfs However they're much more light-weight No atomic access of all sysfs properties Sysfs is limited to page size Properties can be queried by media object, in which case the media object id would be provided The entire tree of properties can be obtained using object id 0 Another option for the kernel interface: key/length/value E.g. type (u32) | length (u32) | value (string) | key (string) Media objects Media objects have an unique ID in the system Objects can be entities, pads or interfaces, for instance A few bits can be reserved for object types, e.g. entity == 0; interface == 1, pad == 2 Action Items: - media_interface/media_topology: RFC for userspace API: Hans - RFC patch series: internal implementation for interface/topology: Mauro - Migration: add v4l-subdev media_interface: Laurent - Migration: add explicit DMA Engine entity: Laurent - media_properties: RFC userspace API: Sakari - MC core support for dynamically adding/removing from the media graph: Samsung - Clarify/implement DVB network interface: Mauro - MC support for Alsa: Lars: Need RFC before Alsa summit during ELCE - MC support for DVB: Mauro - MC default core support for interface-centric V4L2: Hans (?) - MC support for IIO: Lars - VIDIOC_ENUMINPUTS/G_TUNER: tell if the tuner/input is busy: RFC Hans, Shuah has a backend for this. - Fix media_device broken alloc/remove (devres): Shuah New include: /* * Multimedia device API * * Copyright (C) 2010 Nokia Corporation * * Contacts: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> * Sakari Ailus <sakari.ailus(a)iki.fi> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __LINUX_MEDIA_H #define __LINUX_MEDIA_H #include <linux/ioctl.h> #include <linux/types.h> #include <linux/version.h> #define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0) struct media_device_info { char driver[16]; char model[32]; char serial[40]; char bus_info[32]; __u32 media_version; __u32 hw_revision; __u32 driver_version; __u32 reserved[31]; }; #define MEDIA_ENT_ID_FLAG_NEXT (1 << 31) #define MEDIA_ENT_TYPE_SHIFT 16 #define MEDIA_ENT_TYPE_MASK 0x00ff0000 #define MEDIA_ENT_SUBTYPE_MASK 0x0000ffff #define MEDIA_ENT_T_DEVNODE (1 << MEDIA_ENT_TYPE_SHIFT) #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) /* Legacy symbol. Use it to avoid userspace compilation breakages */ #define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE #define MEDIA_ENT_T_V4L2_SUBDEV (2 << MEDIA_ENT_TYPE_SHIFT) #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1) #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV + 2) #define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV + 3) /* A converter of analogue video to its digital representation. */ #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4) #define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV + 5) Possible entity types: - connector - source-from-mem/sink-to-mem or memory-transport or dma engine - processing block - controller block - Time division multiplexed busses? Function Properties: - tuner - analog demod, digital demod - analog video decoder/encoder - video receiver/transmitter - audio ADC/DAC - mux/demux - image sensor - flash controller - lens/iris/etc. controllers - network (de)packetizer - audio mixer - deinterlaced - memory transport - scaler - CA - IR - amplifier #define MEDIA_ENT_FL_DEFAULT (1 << 0) struct media_entity_desc { __u32 id; char name[32]; __u32 type; __u32 revision; __u32 flags; __u32 group_id; __u16 pads; __u16 links; __u16 associations; __u16 reserved[7]; union { /* Node specifications */ struct { __u32 major; __u32 minor; } dev; /* Sub-device specifications */ /* Nothing needed yet */ __u8 raw[184]; }; }; #define MEDIA_PAD_FL_SINK (1 << 0) #define MEDIA_PAD_FL_SOURCE (1 << 1) #define MEDIA_PAD_FL_MUST_CONNECT (1 << 2) struct media_pad_desc { __u32 entity; /* entity ID */ __u16 index; /* pad index */ __u32 flags; /* pad flags */ __u32 reserved[2]; }; #define MEDIA_LNK_FL_ENABLED (1 << 0) #define MEDIA_LNK_FL_IMMUTABLE (1 << 1) #define MEDIA_LNK_FL_DYNAMIC (1 << 2) struct media_link_desc { struct media_pad_desc source; // source or controller pad struct media_pad_desc sink; // sink or controllee pad __u32 flags; __u32 reserved[2]; }; struct media_links_enum { __u32 entity; /* Should have enough room for pads elements */ struct media_pad_desc __user *pads; /* Should have enough room for links elements */ struct media_link_desc __user *links; __u32 reserved[4]; }; ////////////////////////////////////////////////////////// #define MEDIA_INTF_T_DVB_FE (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5) #define MEDIA_INTF_T_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6) #define MEDIA_INTF_T_DVB_CA (MEDIA_ENT_T_DEVNODE + 7) #define MEDIA_INTF_T_DVB_NET (MEDIA_ENT_T_DEVNODE + 8) // network interface: requires MC support for dynamically // adding/deleting these interface/entities/links/etc. #define MEDIA_INTF_T_NETIF_DVB (MEDIA_ENT_T_DEVNODE + 8) // ? #define MEDIA_INTF_T_V4L_VIDEO (MEDIA_ENT_T_DEVNODE + 8) #define MEDIA_INTF_T_V4L_VBI (MEDIA_ENT_T_DEVNODE + 8) #define MEDIA_INTF_T_V4L_RADIO (MEDIA_ENT_T_DEVNODE + 8) #define MEDIA_INTF_T_V4L_SUBDEV (MEDIA_ENT_T_DEVNODE + 8) #define MEDIA_INTF_T_V4L_SWRADIO (MEDIA_ENT_T_DEVNODE + 8) #define MEDIA_INTF_T_ALSA_PCM_CAPTURE (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_ALSA_CONTROL (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_ALSA_RAWMIDI (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_ALSA_HWDEP (MEDIA_ENT_T_DEVNODE + 4) #if 0 // sysfs directory #define MEDIA_INTF_T_IIO_DEVICE (MEDIA_ENT_T_DEVNODE + 4) #define MEDIA_INTF_T_IIO_BUFFER (MEDIA_ENT_T_DEVNODE + 4) #endif struct media_interface { __u32 id; __u32 type; // 'Default interface' concept should be documented // in more detail. __u32 flags; __u32 num_interface_links; union { /* Node specifications */ // Split up node spec + subsystem info in separate // unions. struct { __u32 major; __u32 minor; } devnode; // struct { // __s32 if_index; // TBC // } netif; // struct { // __u32 id; // } iio_device; // Full pathname or similar should be passed as a property __u32 raw[16]; }; }; struct media_entity { __u32 id; __u32 flags; // Add connector flag //__u32 group_id; // removed: use properties instead __u16 num_pads; }; struct media_pad { __u32 entity_id; __u16 id; /* pad id (assuming unique pad ID) */ __u16 num_links; __u32 flags; }; // Should we have unique pad IDs? // If so, should we drop the source/sink_id fields? struct media_link { __u32 id; __u32 source_id; __u32 source_pad_id; __u32 sink_id; __u32 sink_pad_id; __u32 flags; // NON_DIRECTIONAL, BIDIRECTIONAL, UNIDIRECTIONAL // Also available in pads }; struct media_interface_link { __u32 id; __u32 interface_id; __u32 entity_id; __u32 flags; }; enum { MEDIA_PROP_T_STRING, MEDIA_PROP_T_U32, MEDIA_PROP_T_FOO, }; struct media_property { const char *key; __u32 object_id; // ? __u32 type; union { // based on type const char *string; __u32 *val; struct foo *foo_val; }; }; // id == entity/interface/pad // Idea: use the lower X bits to determine the type. // Not expose this to userspace struct media_properties { __u32 object_id; __u32 num_props; __u32 blob_size; struct media_property *props; __u8 *blob; }; //blob = malloc(blob_size); struct media_topology { __u32 topology_version; __u32 num_entities; struct media_entity *entities; __u32 num_interfaces; struct media_interface *interfaces; __u32 num_pads; struct media_pad *pads; __u32 num_links; struct media_link *links; __u32 num_interface_links; struct media_interface_link *interface_links; struct media_properties properties; }; //struct media_links { // __u32 topology_version; // __u32 num_links; // struct media_link *links; // __u32 num_interface_links; // struct media_interface_link *interface_links; //}; #define MEDIA_IOC_DEVICE_INFO _IOWR('|', 0x00, struct media_device_info) #define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct media_entity_desc) #define MEDIA_IOC_ENUM_LINKS _IOWR('|', 0x02, struct media_links_enum) #define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc) #define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_topology) //#define MEDIA_IOC_SETUP_LINKS _IOWR('|', 0x05, struct media_links) #endif /* __LINUX_MEDIA_H */

1 0

Hybrid analog/digital TV device representation
by Mauro Carvalho Chehab 31 Jul '15

31 Jul '15

For today's discussions: I guess this is how we want to represent the graph of a hybrid TV device. Regards, Mauro

1 3

Fw: Kernel Media Summit Videoconference Request
by Mauro Carvalho Chehab 29 Jul '15

29 Jul '15

Just to remind: tomorrow morning we'll be at Samsung's office. Forwarded message: Date: Wed, 29 Jul 2015 09:51:57 +0300 Subject: RE: Kernel Media Summit Videoconference Request Hi Mauro, The video conference was tested on Monday and the connection works. Are there any procedures to get into the office? - The address is Innopoli 3, Vaisalantie 4, Espoo. No special procedures to get in, just ask for me in the reception. Do we have Internet available there for the Media Controller attendants? - Yes, there will be wifi available for the attendants. Do you need the name of the people that will be tomorrow at the office? - If you have a list of names it would be helpful. - I would like to emphasize that our video conference room holds up to 12 people, no more than that. -- Cheers, Mauro

1 0

Wednesday morning: breakfast, departure to Intel
by Hans Verkuil 27 Jul '15

27 Jul '15

Hi all, Unless someone objects (please reply to this email if that's the case) Sakari will pick us up from the hotel at 8:45 on Wednesday morning so we'll can start at the Intel office at 9am. For those who stay in the hotel: let's have breakfast at 8 am. I suggest the same times for Thursday and Friday, but we can pin that down on Wednesday. Regards, Hans

1 0

[PATCH_RFC 0/2] Media Controller: add support for control elements
by Mauro Carvalho Chehab 27 Jul '15

27 Jul '15

This series is actually food for our meetings at the Media Controller Summit ;) It contains two patches that allows reusing the current media functions for control pipelines with should have entities, links, pads too, in a similar way to what's done to epresent the data pipeline. I'm borrowing the ITU-T/IEEE nomenclature to describe the control elements. On ITU-T documents (also used by IETF on several Internet RFCs), there are 3 planes. We're actually using two of them: - data plane: contains elements, functions and pipelines that handle the data traffic/streams; - control plane: contains elements, functions and pipelines that handle the control of the elements of some infrastructure. The approach taken is to add an extra field at the Kernel internal field specifying if an element/pad/link belongs to either data or control plane (or both). Please notice that this RFC patches don't touch at the userspace API. There are several options that were discussed since December, 2014. Whatever done, we'll need to create support at MC. With this approach, the changes internally will be minimum and independent of whatever API we decide. Please also notice that this is compile-tested only. Futher tests are needed. Mauro Carvalho Chehab (2): media: add support for control entities/links/pads at MC media: Allow usage media_entity_graph_walk_next for control elements drivers/media/media-device.c | 54 ++++++++++++++++--------- drivers/media/media-entity.c | 32 +++++++++++---- drivers/media/platform/exynos4-is/media-dev.c | 4 +- drivers/media/platform/omap3isp/isp.c | 6 +-- drivers/media/platform/omap3isp/ispvideo.c | 2 +- drivers/media/platform/vsp1/vsp1_video.c | 2 +- drivers/media/platform/xilinx/xilinx-dma.c | 2 +- drivers/staging/media/davinci_vpfe/vpfe_video.c | 6 +-- drivers/staging/media/omap4iss/iss.c | 6 +-- drivers/staging/media/omap4iss/iss_video.c | 4 +- include/media/media-entity.h | 54 ++++++++++++++++++++++++- 11 files changed, 130 insertions(+), 42 deletions(-) -- 2.4.3

1 0

Agenda for the Helsinki MC workshop
by Hans Verkuil 20 Jul '15

20 Jul '15

Hi all, Here is a rough draft of the agenda. Note that I have postponed the ALSA/IIO parts to day 2 since Shuah arrives late on day 1. Lars-Peter, if you think the IIO/ASoC presentations/discussions should be moved to day 1 since that is really relevant, then let us know. Since this is a brainstorm meeting the agenda is very high level and totally unreliable :-) The goal is to make the MC API work for new subsystems and if we are more likely to achieve that by rearranging the agenda, then we'll do that. Day 0 (i.e. before the workshop starts!) Everyone should read through the links provided by Mauro in the workshop announcement and the RFC for the property API (see the link below). We don't want to have to repeat everything again during the workshop. Day 1: Discuss the MC+DVB API. In my view the core conflict is about how to represent interfaces and the control links between interfaces and entities. We need to decide on this first before we can go on to other MC topics, I proposed a solution for this (http://www.spinics.net/lists/linux-media/msg91365.html) and we need to discuss if this works for modeling DVB and V4L devices. If we agree that my proposal is a good starting point, then we need to discuss the following open issues that I didn't pin down in my proposal: - how to represent the control links between interfaces and entities - property API (http://www.spinics.net/lists/linux-media/msg90160.html) - how should the 'dev' struct in struct media_entity_desc be used if we have multiple interfaces controlling this entity? If my proposal is rejected, then we will have to come up with an alternative and the remainder of the agenda will be highly uncertain. Day 2: Start with the IIO and ASoC presentations. Continue the Day 1 discussions if needed. Day 2+3: Discuss MC+ALSA+IIO. Time Division Multiplexed pipelines: how to represent those in the MC? Discuss my VIDIOC_SUBDEV_QUERYCAP proposal: v2: https://www.mail-archive.com/linux-media@vger.kernel.org/msg88100.html v3: https://www.mail-archive.com/linux-media@vger.kernel.org/msg90155.html The basic problem (related to the requirements of v4l2-compliance) is that today there is no unique ioctl that all subdev device nodes support (hence the addition of VIDIOC_SUBDEV_QUERYCAP) and that there is no link back from a V4L2, DVB, ALSA, etc. device to the media controller device that it is part of. End of Day 3: Create action items and who will work on each item. Should we make a tech topic proposal for the Kernel Summit? (Need to send it in on this day as well) Regards, Hans

1 0

[ANNOUNCE] Media Controller workshop in Helsinki
by Mauro Carvalho Chehab 08 Jul '15

08 Jul '15

Hi, As discussed on our IRC #v4l channel at Freenode, we'll be running a 3-day Media Controller workshop in Helsinki between July 29-31. The main goal of this workshop is to fixup the problems with the Media Controller API to properly represent device nodes and the control tree, as this is a requirement for the Media Controller to be used by DVB, ALSA and radio devices. This is an invitation-only event, as we want to be sure that we'll have there people that are actively working with the Media Controller, DVB and/or ALSA. So, if you think this is for you, please send us an e-mail. Also, even if you're not able to participate, feel free to submit relevant topics related to the Media Controller, in order to help us to build the workshop's agenda and take other needs into account when working on the needed API changes. As usual, we'll be using the media-workshop(a)linuxtv.org ML for the specific discussions about that, so the ones interested on participate on such discussions and/or be present there are requested to subscribe it, and to submit themes of interest via the mailing lists. For those interested on this theme, I'll add a list of the most relevant past discussions about this theme. Hope to see you there! Regards, Mauro --- The DVB needs with regards to MC are mapped on those two blog entries: http://blogs.s-osg.org/media-controller-support-for-dvb-part-1/ http://blogs.s-osg.org/the-role-of-dtv-network-interfaces-in-media-controll… We had two discussions about MC on our last mini-summit, back on March, 26. The discussions and slides can be found at: http://linuxtv.org/news.php?entry=2015-05-05.mchehab http://www.linuxtv.org/downloads/presentations/media_summit_2015_US/dtv_med… A summary of the issues can also be seen on the emails below: https://www.mail-archive.com/linux-media@vger.kernel.org/msg85910.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg85979.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg83883.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg83884.html Patches that minimally expose DVB via MC were merged on Kernel 4.1, although it is currently marked as BROKEN, in order to tag those API extensions as likely to change on future versions. The initial patchset proposal for ALSA support on MC is there at: http://www.spinics.net/lists/linux-media/msg89574.html The most recent proposal for such fixup can be seen at: http://www.spinics.net/lists/linux-media/msg91365.html

3 2

Topics for HEL
by Lars-Peter Clausen 08 Jul '15

08 Jul '15

Hi, A few things for the meeting in Helsinki. The first two are sessions I can host if there is interest. The other one is a request for discussion. 1. Introduction the Linux IIO framework in the context of the media controller framework The Linux IIO framework is a framework that handles all kind of sensors and converters (like gyroscopes, temperature sensors, precession ADC/DACs, high-speed ADC/DAC, ...). As processing pipelines get more complicated the data flow topology does not necessarily match the control topology. Also there is a trend to towards more integrated solutions which include complex internal processing pipelines in a single chip. For both cases in order for userspace applications to make sense of these setups it is necessary to export the data flow topology. Instead of implementing a custom API the idea is to integrate into the media controller framework. This session will give a quick introduction to the IIO framework and explain its requirements from the media controller framework. 2. Introduction to ALSA/ASoC in the context of media controller framework ALSA is the Linux audio framework and ASoC is a componentizied subsystem in ALSA similar to the subdev subsystem in V4L. This session will do a quick introduction of the basics of both and of ASoC in particular in the context of the media controller framework, giving a overview of the terminology used as well as the internal structuring. 3. How to handle time division multiplexed (TDM) pipelines In a TDM pipeline multiple logically independent channels share the same physical channel but are offset in series in time. A pipeline might be only partially TDMed, meaning some parts of the pipeline process data in series while other parts of the pipeline process data in parallel. Special blocks take care of doing the parallel-to-serial and serial-to-parallel conversion. How to model such a pipeline both in the media controller framework (which is supposed to represent the logical topology [or should it?]) as well as the associated devicetree bindings (which are supposed to represent the physical topology) and how to map between the two. - Lars

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

media-workshop July 2015