hverkuil: regarding your comment on the bus_info in the vimc's configfs patch https://patchwork.kernel.org/patch/10718673/ you worte that the bus_info should be the name of the device set by userspace. This also means that in the querycap https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-capture.c#n60 it will need to access the file->private_data which also means an `open` ioctl shold be implemented. am
I right ?
dafna2: meeting, I'll try to get back to you in 30 min.
dafna2: I'm not sure I understand your question. All I said is that in vimc_probe it should also fill in vimc->mdev.bus_info with the same string that is used by the querycap implementation.
And that is in fact already implemented in vimc today.
hverkuil: but it should use in the querycap the uniq name of device as configured from userspace?
No, I see no reason why userspace would set this.
It's currently "platform:vimc", which is fine.
Only if you can create multiple vimc instances will things get a bit more complex. I can't remember if this patch allows for that.
oh, ok, this is whtat I understood from your comment, "it should be uniq for each media device"
In that case each instance would have an instance number, so you'd get: "platform:vimc-000", "platform:vimc-001" etc. Just like vivid, which allows for multiple instances.
ok, so this should be implemented in the querycap?
the bus_info and mdev.bus_info should be identical strings for the same instance of vimc.
If there is only one instance, then there is nothing to change since it is already correct.
but with the configfs there could be more than one instance
Then you need to add an instance number. And yes, you need to access file->private, but there is no need to make an open() function.
You just add: struct vimc_cap_device *vcap = video_drvdata(file);
just like e.g. vimc_cap_g_fmt_vid_cap does.
Sorry, I said "you need to access file->private", but that's wrong. Just ignore that.
I should somehow keep the runnign index and increment it
You probably want to restrict the number of instances a user can make anyway, so you can use a bitmask or something to keep track of the free instance numbers.
so the index can be stored in a global variable?
dafna2: yes
Kwiboo: Perhaps you can pick PATCH 3/4, "media: hantro: Add helper for the H264 motion vectors allocation" into your series?
it doesn't really belong on my series, as pH5 has pointed out.