On Mon June 4 2012 16:02:12 Laurent Pinchart wrote:
> Hi Oleksiy,
>
> Thank you for the patch.
>
> [CC'ing linux-media]
>
> On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote:
> > Hi Laurent,
> >
> > in attachment is a suggestion patch for media framework and a test
> > program which use this patch.
> >
> > Suddenly we still didn't solved the problem with finding of XU. You
> > know, the proper way to find them is guid (i do not need to explain this
> > :)). Since uvc devices starting to have more and complicated XUs, media
> > api is probably proper way to go - how you suggested.
> >
> > On the wiki of TexasInstruments i found some code examples, how they use
> > this api. And it looks like there is some desing differences between
> > OMPA drivers and UVC. It is easy to find proper entity name for omap
> > devices just by: "(!strcmp(entity[index].name, "OMAP3 ISP CCDC"))".
> > We can't do the same for UVC, current names are just "Extension %u". We
> > can put guid instead, but it will looks ugly and not really informative.
> > This is why i added new struct uvc_ext.
> >
> > If you do not agree with this patch, it will be good if you proved other
> > solution. This problem need to be solved.
>
> The patch goes in the right direction, in that I think the media controller
> API is the proper way to solve this problem. However, extending the
> media_entity_desc structure with information about all possible kinds of
> entities will not scale, especially given that an entity may need to expose
> information related to multiple types (for instance an XU need to expose its
> GUID, but also subdev-related information if it has a device node).
>
> I've been thinking about adding a new ioctl to the media controller API for
> some time now, to report advanced static information about entities.
>
> The idea is that each entity would be allowed to report an arbitrary number
> of
> static items. Items would have a type (for which we would likely need some
> kind of central registry, possible with driver-specific types), a length and
> data. The items would be static (registered an initialization time) and
> aggregated in a single buffer that would be read in one go through a new
> ioctl.
And since it is static the media_entity_desc struct can tell the caller how many
of these items there are, and use that information to retrieve them.
> One important benefit of such an API would be to be able to report more than
> one entity type per subdev using entity type items. Many entities serve
> several purpose, for instance a sensor can integrate a flash controller. This
> can't be reported with the current API, as subdevs have a single type. By
> having several entity type items we could fix this issue.
>
> Details remain to be drafted, but I'd like a feedback on the general approach.
Sound good. We discussed this before, and I agree that these seems to be the
right approach.
Regards,
Hans
--
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
