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

[Sakari Ailus <sakari.ailus@iki.fi>]

Hi Laurent,

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.

I welcome this idea!

Another example of information that's missing currently is the lack of
bus information for the entities: it's next to impossible for the user
space to learn which i2c device a subdev is related to. At the same time
we could deprecate the media_entity_desc.type field.

Providing entity bus information as part of entity enumeration would
resolve this issue.

Btw. do you think a new IOCTL is really required? Why not to just add a
pointer for additional data the user may provide to the driver to fill
up? There's plenty of room in the struct for a pointer and perhaps a
size field.

Cheers,

-- 
Sakari Ailus
sakari.ailus@iki.fi