Re: why is there no enum_input in v4l2_subdev_video_ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Scott,

On Wednesday 11 May 2011 10:43:30 Jiang, Scott wrote:
> On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: > > On Tuesday 10 
May 2011 08:14:10 Hans Verkuil wrote:
> >> > On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote:
> >> >>> >> Why is there no enum_input operation in v4l2_subdev_video_ops?
> >> >> 
> >> >> Why do you need one ?
> >> > 
> >> > Because I want to query decoder how many inputs it can support.
> >> > So the question is where we should store inputs info, board specific
> >> > data or decoder driver?
> >> > I appreciate your advice.
> >> 
> >> ENUMINPUT as defined by V4L2 enumerates input connectors available on
> >> the board. Which inputs the board designer hooked up is something that
> >> only the top-level V4L driver will know. Subdevices do not have that
> >> information, so enuminputs is not applicable there.
> >> 
> >> Of course, subdevices do have input pins and output pins, but these are
> >> assumed to be fixed. With the s_routing ops the top level driver selects
> >> which input and output pins are active. Enumeration of those inputs and
> >> outputs wouldn't gain you anything as far as I can tell since the
> >> subdevice simply does not know which inputs/outputs are actually hooked
> >> up. It's the top level driver that has that information (usually passed
> >> in through board/card info structures).
> > 
> > I agree. Subdevs don't have enough knowledge of their surroundings to
> > make input enumeration really useful. They could enumerate their input
> > pins, but not the inputs that are actually hooked up on board.
> > 
> > The media controller framework is one way of solving this issue. It can
> > report links for every input pad.
> > 
> > Scott, can you tell us a bit more about the decoder you're working with ?
> > What kind of system is it used in ?
> 
> I'm working on ADV7183 and VS6624 connecting with blackfin through ppi.

Enumerating inputs only matters for the ADV7183. The issue is that the adv7183 
driver doesn't know how its inputs are routed on the board. I see several 
solutions to fix this issue.

- Create an adv7183 platform data structure, and fill it in board code with 
input routing information. The adv7183 driver can use that information to 
implement a (to be added) enum_input operation. I don't really like this 
solution, as the adv7183 really shouldn't care about how video signals are 
routed on the board.

- Pass the same information to the master v4l2_device driver that instantiates 
the adv7183. The information can then be used to implement the G_INPUT ioctl, 
or for internal purpose. You won't need any enum_input subdev operation in 
that case.

- Use the media controller API to expose routing information to userspace. 
Like in the previous solution, board code would pass input routing information 
to the v4l2_device driver that would use use to create links. Links will then 
be enumerable and configurable by userspace.

> By the way, ppi is a generic parallel interface, that means it can't know
> the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for
> this info?
> I found it in v4l2_subdev_video_ops, but didn't know its usage exactly.

The enum_mbus_fmt can be used for that purpose, yes. You can use it to query 
the ADV7183 and VS6624 for their supported formats. You can also query the 
current format with g_mbus_fmt.

If you want to implement the media controller API, you should go for the pad-
level operations instead of enum_mbus_fmt/g_mbus_fmt (available in 2.6.39).

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux