Re: [RFC] Representing hardware connections via MC

On 03/02/2016 11:58 PM, Laurent Pinchart wrote: > Hi Mauro, > > (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of > a random order. I would thus recommend reading through it completely before > starting to write a reply.) > > On Wednesday 02 March 2016 12:40:29

[PATCH] v4l2-mc.h: fix compiler warnings

Fix these warnings when CONFIG_MEDIA_CONTROLLER is not defined: In file included from /home/hans/work/build/media-git/drivers/media/v4l2-core/v4l2-fh.c:32:0: /home/hans/work/build/media-git/include/media/v4l2-mc.h:173:12: warning: 'v4l_enable_media_source' defined but not used

Re: [PATCH for 4.5] media.h: use hex values for the range offsets, move connectors base up.

Hi Hans, On Mon, Feb 29, 2016 at 09:02:47AM +0100, Hans Verkuil wrote: > Make the base offset hexadecimal to simplify debugging since the base > addresses are hex too. > > The offsets for connectors is also changed to start after the 'reserved' > range 0x1-0x2. > > Signed-off-by: Hans

Re: tw686x driver

On 03/03/2016 07:51 AM, Krzysztof Hałasa wrote: > Hi Hans, > > Hans Verkuil writes: > >> So lessons learned: >> >> Krzysztof, next time don't wait many months before posting a new version >> fixing >> requested changes. > > Actually, this is not how it happened. > > On

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

Hi Morimoto-sa, On Thursday 03 March 2016 07:19:20 Kuninori Morimoto wrote: > Hi Laurent > > >> It seems FCP clock is based on each SoC > >> In H3 ES1 case, it is using > >> > >> - s2d2 (for 200MHz) > >> - s2d1 (for 400MHz) > > > > Thank you for the information. Do you mean that different

Re: i.mx6 camera interface (CSI) and mainline kernel

On 03/03/2016 03:02 AM, Steve Longerbeam wrote: > On 02/25/2016 02:05 PM, Laurent Pinchart wrote: >> Hello Philippe, >> >> CC'ing Philipp and Steve. >> >> Philipp, Steve, are you still interested in getting a driver for the i.MX6 >> camera interface upstreamed ? > > Hi Laurent, Philippe(s), > >

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

Hi Laurent > > It seems FCP clock is based on each SoC > > In H3 ES1 case, it is using > > - s2d2 (for 200MHz) > > - s2d1 (for 400MHz) > > Thank you for the information. Do you mean that different FCP instances use > different clocks ? If so, could you tell us which clock is used by each >

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

Hi Morimoto-san, On Thursday 03 March 2016 00:17:54 Kuninori Morimoto wrote: > Hi Laurent > > >>> The parent clock isn't documented in the datasheet, use S2D1 as a best > >>> guess for now. > >> > >> Would you be able to find out what the parent clock is for the FCP and > >> LVDS (patch 2/9)

Re: tw686x driver

Hi Hans, Hans Verkuil writes: > So lessons learned: > > Krzysztof, next time don't wait many months before posting a new version > fixing > requested changes. Actually, this is not how it happened. On July 3, 2015 I posted the original driver:

cron job: media_tree daily build: WARNINGS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Mar 3 04:00:23 CET 2016 git branch: test git hash: 697fe725f37aaa5fb15f581bc6e5b588f5fc8f7b gcc

[PATCH] media: au0828 audio mixer isn't connected to decoder

When snd_usb_audio gets probed first, audio mixer doesn't get linked to the decoder. Change au0828_media_graph_notify() to handle the mixer entity getting registered before the decoder. Change au0828_media_device_register() to invoke au0828_media_graph_notify() to connect entites that were

[PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

On Wed, Mar 02, 2016 at 12:32:39PM +0100, Hans Verkuil wrote: > Hi Simon, > > Note that the patch subject still mentions sh_vou. > > Otherwise: > > Acked-by: Hans Verkuil [snip] On Wed, Mar 02, 2016 at 04:17:10PM +0300, Sergei Shtylyov wrote: [snip] > >v2 > >* Do

[PATCH v3] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Acked-by: Geert

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

Hi Laurent > > > The parent clock isn't documented in the datasheet, use S2D1 as a best > > > guess for now. > > > > Would you be able to find out what the parent clock is for the FCP and LVDS > > (patch 2/9) clocks ? It seems FCP clock is based on each SoC In H3 ES1 case, it is using - s2d2

Re: [RFC] Representing hardware connections via MC

Hi Mauro, On Wednesday 02 March 2016 09:32:26 Mauro Carvalho Chehab wrote: > Em Wed, 02 Mar 2016 13:16:47 +0200 Laurent Pinchart escreveu: > > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: > >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: > >>> On Friday 26

Re: [RFC] Representing hardware connections via MC

Hi Mauro, On Wednesday 02 March 2016 16:31:54 Mauro Carvalho Chehab wrote: > Em Wed, 02 Mar 2016 19:33:26 +0100 Hans Verkuil escreveu: > > On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote: > >> Em Wed, 02 Mar 2016 12:28:10 +0100 Hans Verkuil escreveu: > >>> On 03/02/16 12:16, Laurent Pinchart

RE: [PATCH v3 0/8] i2c mux cleanup and locking update

Wolfram Sang wrote: > On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote: > > > > Hi! > > > > [doing a v3 even if there is no "big picture" feedback yet, but > > previous versions has bugs that make them harder to test than > > needed, and testing is very much desired] > > > > I have

Re: [RFC] Representing hardware connections via MC

Hi Mauro, (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of a random order. I would thus recommend reading through it completely before starting to write a reply.) On Wednesday 02 March 2016 12:40:29 Mauro Carvalho Chehab wrote: > Em Wed, 02 Mar 2016 16:16:43 +0200

Re: [PATCH v5 22/22] sound/usb: Use Media Controller API to share media resources

On 03/02/2016 01:41 PM, Dan Carpenter wrote: > On Wed, Mar 02, 2016 at 09:50:31AM -0700, Shuah Khan wrote: >> +mctl = kzalloc(sizeof(*mctl), GFP_KERNEL); >> +if (!mctl) >> +return -ENOMEM; >> + >> +mctl->media_dev = mdev; >> +if (stream == SNDRV_PCM_STREAM_PLAYBACK) {

Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support

Hi Kaneko-san, On 2016-03-03 02:26:41 +0900, Yoshihiro Kaneko wrote: > Hi Hans, > > 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > > Huh, you must have missed Niklas's work the rcar-vin driver: > > > > http://www.spinics.net/lists/linux-media/msg97816.html > > > > I expect that

Re: [PATCH v5 22/22] sound/usb: Use Media Controller API to share media resources

On Wed, Mar 02, 2016 at 09:50:31AM -0700, Shuah Khan wrote: > + mctl = kzalloc(sizeof(*mctl), GFP_KERNEL); > + if (!mctl) > + return -ENOMEM; > + > + mctl->media_dev = mdev; > + if (stream == SNDRV_PCM_STREAM_PLAYBACK) { > + intf_type =

Re: [RFC] Representing hardware connections via MC

Em Wed, 02 Mar 2016 19:33:26 +0100 Hans Verkuil escreveu: > On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote: > > Em Wed, 02 Mar 2016 12:28:10 +0100 > > Hans Verkuil escreveu: > > > >> On 03/02/16 12:16, Laurent Pinchart wrote: > >>> Hi Mauro, >

Re: [PATCH v2 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support

The new way of writing the subject prefix is "ARM: dts: lager: ..." -- 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: [RFC] Representing hardware connections via MC

On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote: > Em Wed, 02 Mar 2016 12:28:10 +0100 > Hans Verkuil escreveu: > >> On 03/02/16 12:16, Laurent Pinchart wrote: >>> Hi Mauro, >>> >>> On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: Em Wed, 02 Mar 2016

Re: [RFC] Representing hardware connections via MC

On 03/02/2016 05:04 PM, Mauro Carvalho Chehab wrote: > Em Wed, 2 Mar 2016 12:40:29 -0300 > Mauro Carvalho Chehab escreveu: > >> After all the discussions, I guess "CONN" for connection is the best way >> to represent it. > > Better to put it on a patch. > > Please

Re: [RFC] Representing hardware connections via MC

On 03/02/2016 09:04 AM, Mauro Carvalho Chehab wrote: > Em Wed, 2 Mar 2016 12:40:29 -0300 > Mauro Carvalho Chehab escreveu: > >> After all the discussions, I guess "CONN" for connection is the best way >> to represent it. > > Better to put it on a patch. > > Please

Re: [PATCH v3 0/8] i2c mux cleanup and locking update

On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote: > From: Peter Rosin > > Hi! > > [doing a v3 even if there is no "big picture" feedback yet, but > previous versions has bugs that make them harder to test than > needed, and testing is very much desired] > > I have

Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support

Hi Hans, 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > Huh, you must have missed Niklas's work the rcar-vin driver: > > http://www.spinics.net/lists/linux-media/msg97816.html > > I expect that the old soc-camera driver will be retired soon in favor of > the new driver, so I

[PATCH v2 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support

From: William Towle Add DT entries for vin0, vin0_pins, and adv7612. Signed-off-by: William Towle Signed-off-by: Rob Taylor [uli: added interrupt, renamed endpoint] Signed-off-by: Ulrich Hecht

[PATCH v2 9/9] ARM: shmobile: lager dts: specify default-input for ADV7612

From: Ian Molton Set the 'default-input' property for ADV7612, enabling image and video capture without the need to have userspace specifying routing. (This version places the property in the adv7612 node, in line with Ian's documentation) Signed-off-by: Ian Molton

[PATCH v2 7/9] media: rcar-vin: initialize EDID data

Initializes the decoder subdevice with a fixed EDID blob. Signed-off-by: Ulrich Hecht --- drivers/media/platform/rcar-vin/rcar-dma.c | 46 ++ 1 file changed, 46 insertions(+) diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c

[PATCH v2 2/9] media: adv7604: automatic "default-input" selection

From: William Towle Add logic such that the "default-input" property becomes unnecessary for chips that only have one suitable input (ADV7611 by design, and ADV7612 due to commit 7111cddd "[media] media: adv7604: reduce support to first (digital) input").

[PATCH v2 5/9] media: rcar-vin: pad-aware driver initialisation

Add detection of source pad number for drivers aware of the media controller API, so that rcar-vin can create device nodes to support modern drivers such as adv7604.c (for HDMI on Lager) and the converted adv7180.c (for composite) underneath. Building rcar_vin gains a dependency on

[PATCH v2 6/9] media: rcar-vin: add DV timings support

Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS, and QUERY_DV_TIMINGS. Signed-off-by: Ulrich Hecht --- drivers/media/platform/rcar-vin/rcar-dma.c | 69 ++ 1 file changed, 69 insertions(+) diff --git

[PATCH v2 3/9] adv7604: fix SPA register location for ADV7612

SPA location LSB register is at 0x70. Signed-off-by: Ulrich Hecht --- drivers/media/i2c/adv7604.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 2097c48..1680c0e 100644 ---

[PATCH v2 4/9] media: rcar_vin: Use correct pad number in try_fmt

Fix rcar_vin_try_fmt's use of an inappropriate pad number when calling the subdev set_fmt function - for the ADV7612, IDs should be non-zero. Signed-off-by: William Towle Reviewed-by: Rob Taylor Acked-by: Hans Verkuil

[PATCH v2 1/9] v4l: subdev: Add pad config allocator and init

From: Laurent Pinchart Add a new subdev operation to initialize a subdev pad config array, and a helper function to allocate and initialize the array. This can be used by bridge drivers to implement try format based on subdev pad operations. Signed-off-by: Laurent

[PATCH v2 0/9] Lager board HDMI input support

Hi! This series implements Lager HDMI input support on top of version 2 of Niklas's herculean rewrite of the rcar-vin driver ("[PATCHv2] [media] rcar-vin: add Renesas R-Car VIN driver"). A couple of the included patches are pushed or have been picked up elsewhere already and are included here

[PATCH v2 1/2] [media] au0828: use standard demod pads struct

As we want au0828 to use the core function to create the MC graphs, use enum demod_pad_index instead of enum au8522_media_pads. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/au8522.h | 9 -

[PATCH v2 2/2] [media] au0828: use v4l2_mc_create_media_graph()

There's no reason to implement its own function to create the media graph. So, use the core one. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/au0828/au0828-video.c | 103 ++-- drivers/media/v4l2-core/v4l2-mc.c | 21

Re: [PATCH 2/2] [media] au0828: use v4l2_mc_create_media_graph()

Hi Mauro, [auto build test ERROR on sailus-media/master] [cannot apply to v4.5-rc6 next-20160302] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/Don-t-duplicate

Re: [RFC] Representing hardware connections via MC

Hello Mauro, On 03/02/2016 01:04 PM, Mauro Carvalho Chehab wrote: Em Wed, 2 Mar 2016 12:40:29 -0300 Mauro Carvalho Chehab escreveu: After all the discussions, I guess "CONN" for connection is the best way to represent it. I agree, after all in the latest

Re: [RFC] Representing hardware connections via MC

Em Wed, 2 Mar 2016 12:40:29 -0300 Mauro Carvalho Chehab escreveu: > After all the discussions, I guess "CONN" for connection is the best way > to represent it. Better to put it on a patch. Please review. Regards, Mauro [media] Better define MEDIA_ENT_F_CONN_*

[PATCH 13/14] [media] omap3isp: use IS_ENABLED() to hide pm functions

The omap3isp driver hides is power management functions using #ifdef but it fails to hide the isp_suspend_modules/isp_resume_modules functions in the same way, which leads to a build warning when CONFIG_PM is disabled: drivers/media/platform/omap3isp/isp.c:1183:12: error: 'isp_suspend_modules'

[PATCH 00/14] drivers: use __maybe_unused to hide pm functions

I found many variations of the bug in these device drivers (and some USB drivers I already send patches for in a separate series). In each case, the power management operations structure conditionally references suspend/resume functions, but the functions are hidden in an incorrect #ifdef or not

Re: [RFC] Representing hardware connections via MC

Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus escreveu: > Hi Mauro, > > On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote: > > We had some discussions on Feb, 12 about how to represent connectors via > > the Media Controller: > >

Re: [PATCH 1/2] [media] au0828: use standard demod pads struct

Hi Mauro, [auto build test WARNING on sailus-media/master] [cannot apply to v4.5-rc6 next-20160302] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/Don-t-duplicate

[PATCH v3] media: Support Intersil/Techwell TW686x-based video capture cards

This commit introduces the support for the Techwell TW686x video capture IC. This hardware supports a few DMA modes, including scatter-gather and frame (contiguous). This commit makes little use of the DMA engine and instead has a memcpy based implementation. DMA frame and scatter-gather modes

Re: [RFC] Representing hardware connections via MC

Hi Mauro, On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote: > We had some discussions on Feb, 12 about how to represent connectors via > the Media Controller: > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27 > > We tried to finish those

[PATCH 0/2] Don't duplicate a function to create graph on au0828

All other drivers are using already the core to create the graph. Do the same for au0828. Mauro Carvalho Chehab (2): [media] au0828: use standard demod pads struct [media] au0828: use v4l2_mc_create_media_graph() drivers/media/dvb-frontends/au8522.h | 9 ---

[PATCH 1/2] [media] au0828: use standard demod pads struct

As we want au0828 to use the core function to create the MC graphs, use enum demod_pad_index instead of enum au8522_media_pads. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/au8522.h | 9 -

[PATCH 2/2] [media] au0828: use v4l2_mc_create_media_graph()

There's no reason to implement its own function to create the media graph. So, use the core one. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/au0828/au0828-video.c | 99 + drivers/media/v4l2-core/v4l2-mc.c | 21 ++-

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

Hello. On 3/2/2016 4:14 AM, Simon Horman wrote: Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority

Re: [RFC] Representing hardware connections via MC

Em Wed, 02 Mar 2016 13:16:47 +0200 Laurent Pinchart escreveu: > Hi Mauro, > > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: > > Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: > > > On Friday 26 February 2016 09:13:17 Mauro

Re: [RFC] Representing hardware connections via MC

Em Wed, 02 Mar 2016 12:28:10 +0100 Hans Verkuil escreveu: > On 03/02/16 12:16, Laurent Pinchart wrote: > > Hi Mauro, > > > > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: > >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: > >>> On

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

Hi Simon, Note that the patch subject still mentions sh_vou. Otherwise: Acked-by: Hans Verkuil Regards, Hans On 03/02/16 12:00, Laurent Pinchart wrote: > Hi Simon, > > Thank you for the patch. > > On Wednesday 02 March 2016 10:14:51 Simon Horman wrote: >>

Re: [RFC] Representing hardware connections via MC

On 03/02/16 12:16, Laurent Pinchart wrote: > Hi Mauro, > > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: >>> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote: > > [snip] > NOTE: The

Re: [RFC] Representing hardware connections via MC

Hi Mauro, On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote: > Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: > > On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote: [snip] > >> NOTE: > >> > >> The labels at the PADs currently can't be represented, but

[PATCH] [media] rc-core: allow calling rc_open with device not initialized

The device initialization completes only after calling input_register_device(). However, rc_open() can be called while the device is being registered by the input/evdev core. So, we can't expect that rc_dev->initialized to be true. Change the logic to don't require initialized == true at rc_open

[PATCH 1/2] dw2102: ts2020 included twice

ts2020.h was already included a few lines earlier. Remove the unnecessary entry. Signed-off-by: Olli Salonen --- drivers/media/usb/dvb-usb/dw2102.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dw2102.c

Re: [RFC] Representing hardware connections via MC

Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu: > Hi Mauro, > > Thank you for the summary. > > On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote: > > We had some discussions on Feb, 12 about how to represent connectors via > > the

[PATCH 2/2] dw2102: add support for TeVii S662

TeVii S662 is a USB 2.0 DVB-S2 tuner that's identical to TechnoTrend S2-4600 tuner. Add the USB ID to dw2102 driver. Signed-off-by: Olli Salonen --- drivers/media/usb/dvb-usb/dw2102.c | 23 +-- 1 files changed, 17 insertions(+), 6 deletions(-) diff

Re: [RFC] Representing hardware connections via MC

Hi Javier, On Friday 26 February 2016 10:13:48 Javier Martinez Canillas wrote: > On 02/26/2016 09:13 AM, Mauro Carvalho Chehab wrote: > > We had some discussions on Feb, 12 about how to represent connectors via > > > > the Media Controller: > >

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

Hi Simon, Thank you for the patch. On Wednesday 02 March 2016 10:14:51 Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more

Re: Problem since commit c73bbaa4ec3e [rc-core: don't lock device at rc_register_device()]

Em Sat, 27 Feb 2016 22:42:24 +0100 Heiner Kallweit escreveu: > Am 27.02.2016 um 20:50 schrieb Mauro Carvalho Chehab: > > Em Sat, 27 Feb 2016 19:39:16 +0100 > > Heiner Kallweit escreveu: > > > >> Am 27.02.2016 um 19:05 schrieb Mauro Carvalho Chehab:

Re: [RFC] Representing hardware connections via MC

Hi Mauro, Thank you for the summary. On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote: > We had some discussions on Feb, 12 about how to represent connectors via > the Media Controller: > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27 > > We tried to