On 08/11/15 11:36, Mauro Carvalho Chehab wrote: > Em Tue, 11 Aug 2015 11:28:25 +0200 > Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > >> Hi Helen, >> >> On 08/10/15 19:21, Helen Fornazier wrote: >>> Hi, thanks for your reviews >>> >>> On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>>> Hi Helen! >>>> >>>> On 08/08/2015 03:55 AM, Helen Fornazier wrote: >>>>> Hi! >>>>> >>>>> I've made a first sketch about the API of the vimc driver (virtual >>>>> media controller) to configure the topology through user space. >>>>> As first suggested by Laurent Pinchart, it is based on configfs. >>>>> >>>>> I would like to know you opinion about it, if you have any suggestion >>>>> to improve it, otherwise I'll start its implementation as soon as >>>>> possible. >>>>> This API may change with the MC changes and I may see other possible >>>>> configurations as I implementing it but here is the first idea of how >>>>> the API will look like. >>>>> >>>>> vimc project link: https://github.com/helen-fornazier/opw-staging/ >>>>> For more information: http://kernelnewbies.org/LaurentPinchart >>>>> >>>>> /*********************** >>>>> The API: >>>>> ************************/ >>>>> >>>>> In short, a topology like this one: http://goo.gl/Y7eUfu >>>>> Would look like this filesystem tree: https://goo.gl/tCZPTg >>>>> Txt version of the filesystem tree: https://goo.gl/42KX8Y >>>>> >>>>> * The /configfs/vimc subsystem >>>> >>>> I haven't checked the latest vimc driver, but doesn't it support >>>> multiple instances, just like vivid? I would certainly recommend that. >>> >>> Yes, it does support >>> >>>> >>>> And if there are multiple instances, then each instance gets its own >>>> entry in configfs: /configs/vimc0, /configs/vimc1, etc. >>> >>> You are right, I'll add those >>> >>>> >>>>> The vimc driver registers a subsystem in the configfs with the >>>>> following contents: >>>>> > ls /configfs/vimc >>>>> build_topology status >>>>> The build_topology attribute file will be used to tell the driver the >>>>> configuration is done and it can build the topology internally >>>>> > echo -n "anything here" > /configfs/vimc/build_topology >>>>> Reading from the status attribute can have 3 different classes of outputs >>>>> 1) deployed: the current configured tree is built >>>>> 2) undeployed: no errors, the user has modified the configfs tree thus >>>>> the topology was undeployed >>>>> 3) error error_message: the topology configuration is wrong >>>> >>>> I don't see the status file in the filesystem tree links above. >>> >>> Sorry, I forgot to add >>> >>>> >>>> I actually wonder if we can't use build_topology for that: reading it >>>> will just return the status. >>> >>> Yes we can, I was just wondering what should be the name of the file, >>> as getting the status from reading the build_topology file doesn't >>> seem much intuitive >> >> I'm not opposed to a status file, but it would be good to know what Laurent >> thinks. >> >>> >>>> >>>> What happens if it is deployed and you want to 'undeploy' it? Instead of >>>> writing anything to build_topology it might be useful to write a real >>>> command to it. E.g. 'deploy', 'destroy'. >>>> >>>> What happens when you make changes while a topology is deployed? Should >>>> such changes be rejected until the usecount of the driver goes to 0, or >>>> will it only be rejected when you try to deploy the new configuration? >>> >>> I was thinking that if the user try changing the topology, or it will >>> fail (because the device instance is in use) or it will undeploy the >>> old topology (if the device is not in use). Then a 'destroy' command >>> won't be useful, the user can just unload the driver when it won't be >>> used anymore, > > Well, we're planning to add support for dynamic addition/removal of > entities, interfaces, pads and links. So, instead of undeploy the > old topology, one could just do: > rm -rf <part of the tree> Dynamic entities and interfaces yes, but dynamic pads? The entity defines the number of pads it has, which is related to the hardware or IP properties of the entity. I don't see how that can be dynamic. I certainly wouldn't bother with that in vimc. 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
