All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum
Date: Mon, 21 Mar 2016 21:22:01 -0300	[thread overview]
Message-ID: <56F09029.1060809@osg.samsung.com> (raw)
In-Reply-To: <20160321181532.58827d37@recife.lan>

Hello Mauro,

On 03/21/2016 06:15 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Mar 2016 16:48:12 -0300
> Javier Martinez Canillas <javier@osg.samsung.com> escreveu:
> 
>> Hello Hans,
>>
>> On 03/21/2016 04:30 PM, Hans Verkuil wrote:
>>
>> [snip]
>>
>>>>>>
>>>>>> Can you please provide an example of a media pipeline that user-space should
>>>>>> use with this approach? AFAICT whatever PADs are created when initiliazing
>>>>>> the PADs for an entity, will be exposed to user-space in the media graph.
>>>>>>
>>>>>> So I'm not understading how it will be used in practice. I don't mean that
>>>>>> your approach is not correct, is just I'm not getting it :)  
>>>>>
>>>>> Why would userspace need to use the pads? This is for legacy drivers (right?)
>>>>> where the pipeline is fixed anyway.
>>>>>  
>>>>
>>>> I asked because the user needs to setup the links in the media pipeline to
>>>> choose  which input connection will be linked to the tvp5150 decoder. But it
>>>> doesn't matter if we are going with the single sink pad approach since the
>>>> user will always do something like:  
>>>
>>> Why? The user will use an application that uses ENUM/S/G_INPUT for this. We're
>>> talking legacy drivers ('interface centric drivers' would be a better description)
>>> where we don't even expose the v4l-subdevX device nodes. Explicitly programming
>>> a media pipeline is something you do for complex devices (embedded systems and
>>> the like). Not for simple and generally fixed pipelines. Utterly pointless.
>>>  
>>
>> Mauro was talking about legacy 'interface centric' PC-consumer's hardware but
>> my test system is an embedded board that also has a tvp5150 decoder. The
>> board has an OMAP3 and the tvp5150 is attached to the SoC ISP. Is this one:
>>
>> https://www.isee.biz/products/igep-expansion-boards/igepv2-expansion
> 
> Yeah, subdevs should be prepared to work with both "interface centric" and
> "media controller centric" approaches.
> 
> Yet, I don't think using one sink pad for tvp5150 is a bad thing.
> 
>> As you can see, the board has 2 RCA connectors and each one is routed a tvp5150
>> composite input and both connectors can be used for S-Video. So the user needs
>> to setup the pipeline manually to choose which input connection to use.
> 
> Actually, on your tests, you were not able to make this work, nor
> S-Video is officially supported by the manufacturer. So, in the
> specific case of IGEPv2, I would not be adding a S-Video connector.
>

Yes, we can leave that for now. As you said I was not able to make it
work and when contacted an engineer working for the manufacturer, he
told me that in theory it should work but they have never tested it.

> Btw, even on devices with an S-Video connector and tvp5150, at
> least on my tests, the driver were not able to setup S-Video. It
> seems that there's something more than just setting the mux.
>

That could explain why it was not working for me, but in any case I
can focus on the two composite inputs for now that I can test on my
board easily. The S-video input support can be added as follow up.

> - 
> Thanks,
> Mauro
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

  reply	other threads:[~2016-03-22  0:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09 19:09 [RFC PATCH 0/3] [media] tvp515p: Proposal for MC input connector support Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum Javier Martinez Canillas
2016-03-18 15:45   ` Hans Verkuil
2016-03-18 17:33     ` Hans Verkuil
2016-03-21 14:40       ` Mauro Carvalho Chehab
2016-03-21 15:05         ` Hans Verkuil
2016-03-21 16:01           ` Hans Verkuil
2016-03-21 17:50             ` Mauro Carvalho Chehab
2016-03-21 18:08               ` Hans Verkuil
2016-03-21 18:23                 ` Mauro Carvalho Chehab
2016-03-21 18:48                   ` Hans Verkuil
2016-03-21 18:24                 ` Javier Martinez Canillas
2016-03-21 18:34                   ` Mauro Carvalho Chehab
2016-03-21 18:38                     ` Javier Martinez Canillas
2016-03-21 18:51                     ` Hans Verkuil
2016-03-21 19:06                   ` Hans Verkuil
2016-03-21 19:20                     ` Javier Martinez Canillas
2016-03-21 19:30                       ` Hans Verkuil
2016-03-21 19:48                         ` Javier Martinez Canillas
2016-03-21 21:15                           ` Mauro Carvalho Chehab
2016-03-22  0:22                             ` Javier Martinez Canillas [this message]
2016-03-21 21:20                       ` Mauro Carvalho Chehab
2016-03-22  0:16                         ` Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 2/3] [media] tvp5150: Add input connectors DT bindings Javier Martinez Canillas
2016-03-09 19:09 ` [RFC PATCH 3/3] [media] tvp5150: Replace connector support according to DT binding Javier Martinez Canillas
2016-03-18 15:01 ` [RFC PATCH 0/3] [media] tvp515p: Proposal for MC input connector support Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56F09029.1060809@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shuahkh@osg.samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.