> 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.
Definitely not.
> - 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.
This is the way to do it. The TI davinci drivers do this, for example.
> - 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.
This does not work (yet), since this would require the MC to have
connector entities which we do not have (yet). We will need them for ALSA,
and I think we also need them for V4L, but for V4L we need to figure out
the relationship between the _INPUT and _OUTPUT V4L2 ioctls and a MC with
connector entities first.
Regards,
Hans
>> 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
>
--
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
