All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 2/2] v4l: Add support for STD ioctls on subdev nodes
Date: Fri, 29 Jun 2018 09:28:56 -0300	[thread overview]
Message-ID: <20180629092856.73406202@coco.lan> (raw)
In-Reply-To: <1b948535-8067-fef6-efd9-92aff3049ec5@xs4all.nl>

Em Fri, 29 Jun 2018 12:26:20 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 06/29/18 12:06, Mauro Carvalho Chehab wrote:
> > Em Thu, 28 Jun 2018 14:47:05 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >   
> >> On 06/28/18 13:37, Mauro Carvalho Chehab wrote:  
> >>> Em Thu, 17 May 2018 16:30:16 +0200
> >>> Niklas Söderlund         <niklas.soderlund+renesas@ragnatech.se> escreveu:
> >>>     
> >>>> There is no way to control the standard of subdevices which are part of
> >>>> a media device. The ioctls which exists all target video devices
> >>>> explicitly and the idea is that the video device should talk to the
> >>>> subdevice. For subdevices part of a media graph this is not possible and
> >>>> the standard must be controlled on the subdev device directly.    
> >>>
> >>> Why isn't it possible? A media pipeline should have at least a video
> >>> devnode where the standard ioctls will be issued.    
> >>
> >> Not for an MC-centric device like the r-car or imx. It's why we have v4l-subdev
> >> ioctls for the DV_TIMINGS API, but the corresponding SDTV standards API is
> >> missing.
> >>
> >> And in a complex scenario there is nothing preventing you from having multiple
> >> SDTV inputs, some of which need PAL-BG, some SECAM, some NTSC (less likely)
> >> which are all composed together (think security cameras or something like that).
> >>
> >> You definitely cannot set the standard from a video device. If nothing else,
> >> it would be completely inconsistent with how HDMI inputs work.
> >>
> >> The whole point of MC centric devices is that you *don't* control subdevs
> >> from video nodes.  
> > 
> > Well, the way it is, this change is disruptive, as, as far as I remember,
> > MC-based devices with tvp5150 already sets STD via the /dev/video device.  
> 
> Really? Which driver? I am not aware of this and I think you are mistaken.
> Remember that we are talking about MC-centric drivers. em28xx is not MC-centric,
> even though it has a media device.

OMAP3. There are some boards out there with tvp5150.

> 
> > 
> > If we're willing to add it, we'll need to be clear when one approach
> > should be taken, and be clear that, if the SUBDEV version is used, the
> > driver should not support the non-subdev option.  
> 
> Of course, but in the case of em28xx the tvp5150 v4l-subdev node is never
> created, so this is not a problem.
> 
> Regards,
> 
> 	Hans
> 
> >   
> >>
> >> Regards,
> >>
> >> 	Hans
> >>  
> >>> So, I don't see why you would need to explicitly set the standard inside
> >>> a sub-device.
> >>>
> >>> The way I see, inside a given pipeline, all subdevs should be using the
> >>> same video standard (maybe except for a m2m device with would have some
> >>> coded that would be doing format conversion).
> >>>
> >>> Am I missing something?
> >>>
> >>> Thanks,
> >>> Mauro
> >>>     
> >>  
> > 
> > 
> > 
> > Thanks,
> > Mauro
> >   
> 



Thanks,
Mauro

  reply	other threads:[~2018-06-29 12:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 14:30 [PATCH v2 0/2] v4l: Add support for STD ioctls on subdev nodes Niklas Söderlund
2018-05-17 14:30 ` [PATCH v2 1/2] v4l2-ioctl: create helper to fill in v4l2_standard for ENUMSTD Niklas Söderlund
2018-05-17 14:30 ` [PATCH v2 2/2] v4l: Add support for STD ioctls on subdev nodes Niklas Söderlund
2018-06-28 11:37   ` Mauro Carvalho Chehab
2018-06-28 12:47     ` Hans Verkuil
2018-06-29 10:06       ` Mauro Carvalho Chehab
2018-06-29 10:26         ` Hans Verkuil
2018-06-29 12:28           ` Mauro Carvalho Chehab [this message]
2018-06-29 12:32             ` Hans Verkuil
2018-07-04  6:33       ` Niklas Söderlund
2018-07-04  6:33         ` Niklas Söderlund
2018-07-05 12:44   ` Mauro Carvalho Chehab
2018-07-05 13:12     ` Hans Verkuil
2018-07-08 13:11       ` Javier Martinez Canillas
2018-07-11 10:39         ` Marco Felsch
2018-07-11 10:39           ` Marco Felsch
2018-07-13  9:18           ` Javier Martinez Canillas
2018-07-13 10:54             ` Marco Felsch

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=20180629092856.73406202@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    /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.