Re: [RFC] Media controller entity information ioctl [was "Re: [patch] suggestion for media framework"]

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

 



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