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. 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. -- 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
