[PATCH v2 0/6] media token resource framework
Add media token device resource framework to allow sharing resources such as tuner, dma, audio etc. across media drivers and non-media sound drivers that control media hardware. The Media token resource is created at the main struct device that is common to all drivers that claim various pieces of the main media device, which allows them to find the resource using the main struct device. As an example, digital, analog, and snd-usb-audio drivers can use the media token resource API using the main struct device for the interface the media device is attached to. This patch series consists of media token resource framework and changes to use it in dvb-core, v4l2-core, au0828 driver, and snd-usb-audio driver. With these changes dvb and v4l2 can share the tuner without disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, vlc audio capture option, arecord/aplay during development to identify v4l2 vb2 and vb1 ioctls and file operations that disrupt the digital stream and would require changes to check tuner ownership prior to changing the tuner configuration. vb2 changes are made in the v4l2-core and vb1 changes are made in the au0828 driver to encourage porting drivers to vb2 to advantage of the new media token resource framework with changes in the core. In this patch v2 series, fixed problems identified in the patch v1 series. Important ones are changing snd-usb-audio to use media tokens, holding tuner lock in VIDIOC_ENUMINPUT, and VIDIOC_QUERYSTD. Shuah Khan (6): media: add media token device resource framework media: v4l2-core changes to use media token api media: au0828-video changes to use media token api media: dvb-core changes to use media token api sound/usb: pcm changes to use media token api media: au0828-core changes to create and destroy media MAINTAINERS |2 + drivers/media/dvb-core/dvb_frontend.c | 14 +- drivers/media/usb/au0828/au0828-core.c | 23 +++ drivers/media/usb/au0828/au0828-video.c | 42 +- drivers/media/v4l2-core/v4l2-fh.c |7 + drivers/media/v4l2-core/v4l2-ioctl.c| 61 include/linux/media_tknres.h| 50 +++ lib/Makefile|2 + lib/media_tknres.c | 237 +++ sound/usb/pcm.c |9 ++ 10 files changed, 445 insertions(+), 2 deletions(-) create mode 100644 include/linux/media_tknres.h create mode 100644 lib/media_tknres.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] media token resource framework
At Tue, 14 Oct 2014 08:58:36 -0600, Shuah Khan wrote: > > Add media token device resource framework to allow sharing > resources such as tuner, dma, audio etc. across media drivers > and non-media sound drivers that control media hardware. The > Media token resource is created at the main struct device that > is common to all drivers that claim various pieces of the main > media device, which allows them to find the resource using the > main struct device. As an example, digital, analog, and > snd-usb-audio drivers can use the media token resource API > using the main struct device for the interface the media device > is attached to. > > This patch series consists of media token resource framework > and changes to use it in dvb-core, v4l2-core, au0828 driver, > and snd-usb-audio driver. > > With these changes dvb and v4l2 can share the tuner without > disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, > vlc audio capture option, arecord/aplay during development to > identify v4l2 vb2 and vb1 ioctls and file operations that > disrupt the digital stream and would require changes to check > tuner ownership prior to changing the tuner configuration. > vb2 changes are made in the v4l2-core and vb1 changes are made > in the au0828 driver to encourage porting drivers to vb2 to > advantage of the new media token resource framework with changes > in the core. > > In this patch v2 series, fixed problems identified in the > patch v1 series. Important ones are changing snd-usb-audio > to use media tokens, holding tuner lock in VIDIOC_ENUMINPUT, > and VIDIOC_QUERYSTD. Just took a quick glance over the patches, and my first concern is why this has to be lib/*. This means it's always built-in as long as this config is enabled (and will be so on distro kernel) even if it's not used at all. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] media token resource framework
On 10/15/2014 10:48 AM, Takashi Iwai wrote: > At Tue, 14 Oct 2014 08:58:36 -0600, > Shuah Khan wrote: >> >> Add media token device resource framework to allow sharing >> resources such as tuner, dma, audio etc. across media drivers >> and non-media sound drivers that control media hardware. The >> Media token resource is created at the main struct device that >> is common to all drivers that claim various pieces of the main >> media device, which allows them to find the resource using the >> main struct device. As an example, digital, analog, and >> snd-usb-audio drivers can use the media token resource API >> using the main struct device for the interface the media device >> is attached to. >> >> This patch series consists of media token resource framework >> and changes to use it in dvb-core, v4l2-core, au0828 driver, >> and snd-usb-audio driver. >> >> With these changes dvb and v4l2 can share the tuner without >> disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, >> vlc audio capture option, arecord/aplay during development to >> identify v4l2 vb2 and vb1 ioctls and file operations that >> disrupt the digital stream and would require changes to check >> tuner ownership prior to changing the tuner configuration. >> vb2 changes are made in the v4l2-core and vb1 changes are made >> in the au0828 driver to encourage porting drivers to vb2 to >> advantage of the new media token resource framework with changes >> in the core. >> >> In this patch v2 series, fixed problems identified in the >> patch v1 series. Important ones are changing snd-usb-audio >> to use media tokens, holding tuner lock in VIDIOC_ENUMINPUT, >> and VIDIOC_QUERYSTD. > > Just took a quick glance over the patches, and my first concern is why > this has to be lib/*. This means it's always built-in as long as this > config is enabled (and will be so on distro kernel) even if it's not > used at all. > Right this module gets built when CONFIG_MEDIA_SUPPORT is enabled and stubs are in place when it is not enabled. The intent is for this feature to be enabled by default when media support is enabled. When a driver doesn't create the resource, it will simply not find it and for drivers like snd-usb-audio that aren't tried to media support, the stubs are in place and feature is essentially disabled. I picked lib so this module can be included in non-media drivers e.g: snd-usb-audio. Does this help explain the design? I didn't want to introduce a new config for this feature. If lib isn't right place, could you recommend another one that makes this modules available to non-media drivers? moving isn't a problem. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] media token resource framework
At Wed, 15 Oct 2014 14:21:34 -0600, Shuah Khan wrote: > > On 10/15/2014 10:48 AM, Takashi Iwai wrote: > > At Tue, 14 Oct 2014 08:58:36 -0600, > > Shuah Khan wrote: > >> > >> Add media token device resource framework to allow sharing > >> resources such as tuner, dma, audio etc. across media drivers > >> and non-media sound drivers that control media hardware. The > >> Media token resource is created at the main struct device that > >> is common to all drivers that claim various pieces of the main > >> media device, which allows them to find the resource using the > >> main struct device. As an example, digital, analog, and > >> snd-usb-audio drivers can use the media token resource API > >> using the main struct device for the interface the media device > >> is attached to. > >> > >> This patch series consists of media token resource framework > >> and changes to use it in dvb-core, v4l2-core, au0828 driver, > >> and snd-usb-audio driver. > >> > >> With these changes dvb and v4l2 can share the tuner without > >> disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, > >> vlc audio capture option, arecord/aplay during development to > >> identify v4l2 vb2 and vb1 ioctls and file operations that > >> disrupt the digital stream and would require changes to check > >> tuner ownership prior to changing the tuner configuration. > >> vb2 changes are made in the v4l2-core and vb1 changes are made > >> in the au0828 driver to encourage porting drivers to vb2 to > >> advantage of the new media token resource framework with changes > >> in the core. > >> > >> In this patch v2 series, fixed problems identified in the > >> patch v1 series. Important ones are changing snd-usb-audio > >> to use media tokens, holding tuner lock in VIDIOC_ENUMINPUT, > >> and VIDIOC_QUERYSTD. > > > > Just took a quick glance over the patches, and my first concern is why > > this has to be lib/*. This means it's always built-in as long as this > > config is enabled (and will be so on distro kernel) even if it's not > > used at all. > > > > Right this module gets built when CONFIG_MEDIA_SUPPORT is enabled > and stubs are in place when it is not enabled. The intent is for > this feature to be enabled by default when media support is enabled. > When a driver doesn't create the resource, it will simply not find it > and for drivers like snd-usb-audio that aren't tried to media support, > the stubs are in place and feature is essentially disabled. > > I picked lib so this module can be included in non-media drivers > e.g: snd-usb-audio. > > Does this help explain the design? I didn't want to introduce a new > config for this feature. If lib isn't right place, could you recommend > another one that makes this modules available to non-media drivers? > moving isn't a problem. We can create a small module depending on CONFIG_MEDIA. But it'll be rather a question of the size. If it's reasonably small and generic enough, it's worth to put into lib/*, I think. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] media token resource framework
Hi Shuah and others, Shuah Khan wrote: Add media token device resource framework to allow sharing resources such as tuner, dma, audio etc. across media drivers and non-media sound drivers that control media hardware. The Media token resource is created at the main struct device that is common to all drivers that claim various pieces of the main media device, which allows them to find the resource using the main struct device. As an example, digital, analog, and snd-usb-audio drivers can use the media token resource API using the main struct device for the interface the media device is attached to. This patch series consists of media token resource framework and changes to use it in dvb-core, v4l2-core, au0828 driver, and snd-usb-audio driver. With these changes dvb and v4l2 can share the tuner without disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, vlc audio capture option, arecord/aplay during development to identify v4l2 vb2 and vb1 ioctls and file operations that disrupt the digital stream and would require changes to check tuner ownership prior to changing the tuner configuration. vb2 changes are made in the v4l2-core and vb1 changes are made in the au0828 driver to encourage porting drivers to vb2 to advantage of the new media token resource framework with changes in the core. I know this comes quite late after the first patch series has been sent, but I'd like to ask if you have you considered a different approach: rather than implementing something entirely new, the Media controller can almost do this already. It models the physical layout of the device, instead of creating special use case specific Media entity like constructs for tuner and audio. Also the Media token framework does not appear to be as a perfect match for the Media controller framework which is also planned to be used by DVB already: http://linuxtv.org/news.php?entry=2014-10-21.mchehab>; look for "3) DVB API improvements". There have been ALSA MC patches as well but I'm not aware of the status of those at the moment. The tokens appear much like media entities of specific kind to me. Currently, media entities may only be entities bound to a given subsystem, but I don't think it has to (or perhaps even may) stay that way. In case of the Media controller, mutual exclusion of different users is currently performed by adding the entities to a pipeline and incrementing the streaming count once streaming is enabled --- on different interfaces streaming may mean a different thing. The Media controller interface does not handle serialising potential users that may wish to configure the device. If that's needed then we'll need to think how to add it. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] media token resource framework
Em Wed, 29 Oct 2014 11:17:44 +0200 Sakari Ailus escreveu: > Hi Shuah and others, > > Shuah Khan wrote: > > Add media token device resource framework to allow sharing > > resources such as tuner, dma, audio etc. across media drivers > > and non-media sound drivers that control media hardware. The > > Media token resource is created at the main struct device that > > is common to all drivers that claim various pieces of the main > > media device, which allows them to find the resource using the > > main struct device. As an example, digital, analog, and > > snd-usb-audio drivers can use the media token resource API > > using the main struct device for the interface the media device > > is attached to. > > > > This patch series consists of media token resource framework > > and changes to use it in dvb-core, v4l2-core, au0828 driver, > > and snd-usb-audio driver. > > > > With these changes dvb and v4l2 can share the tuner without > > disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, > > vlc audio capture option, arecord/aplay during development to > > identify v4l2 vb2 and vb1 ioctls and file operations that > > disrupt the digital stream and would require changes to check > > tuner ownership prior to changing the tuner configuration. > > vb2 changes are made in the v4l2-core and vb1 changes are made > > in the au0828 driver to encourage porting drivers to vb2 to > > advantage of the new media token resource framework with changes > > in the core. > > I know this comes quite late after the first patch series has been sent, > but I'd like to ask if you have you considered a different approach: > rather than implementing something entirely new, the Media controller > can almost do this already. It models the physical layout of the device, > instead of creating special use case specific Media entity like > constructs for tuner and audio. Also the Media token framework does not > appear to be as a perfect match for the Media controller framework which > is also planned to be used by DVB already: > > http://linuxtv.org/news.php?entry=2014-10-21.mchehab>; look for "3) > DVB API improvements". There have been ALSA MC patches as well but I'm > not aware of the status of those at the moment. > > The tokens appear much like media entities of specific kind to me. Yeah, it could be seen as that. > Currently, media entities may only be entities bound to a given > subsystem, but I don't think it has to (or perhaps even may) stay that way. We had some discussions about that with Laurent in San Jose. Yeah, we will likely need to change that at the media controller, for complex embedded DVB devices. The usage of the media controller for this specific usage is that we should not force userspace apps to be aware of the media controller just because of hardware locking. > In case of the Media controller, mutual exclusion of different users is > currently performed by adding the entities to a pipeline and > incrementing the streaming count once streaming is enabled --- on > different interfaces streaming may mean a different thing. Well, we'll still need to find a way for ALSA to prevent it to use the audio demod and DMA engine that will be powered off when DVB is streaming. > The Media controller interface does not handle serialising potential > users that may wish to configure the device. If that's needed then we'll > need to think how to add it. Yes, this would be needed needed if we take this approach. Reconfiguring the DMA engine and some other registers via V4L2 API should be blocked. The same applies to firmware load, if the device is using tuner input for analog TV. If we use the media controller, we'll need to add a state to it, to indicate that a block at the pipeline is being reconfigured. Takashi, What's the status of Media Controller adoption on ALSA? Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
