On 04.06.2012 16:02, 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. > > 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. Currently i can talk only about uvc :) Normally entity sub/type can be created by driver and device where documentation is available. For uvc it is not the case. If we get some comlicated uvc device with decumentation about XU, we will need userspace library to map all needed entities. But if you wont to make it static, created on driver init, then we will need some kind of plugin interface for uvcvideo.... (this sounds scary ;)) or remapable entities. Then one more question: for the case with uvcvideo + usb-audio, one of driver may reset complete device if it get some timeout or error. Make it sense to use media api to avoid it? For example uvcvideo set enitity state to busy, and if audio need to reset it and handler is not usb-audio for busy device, then it should notify handler... -- Regards, Oleksij -- 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
