Em Thu, 17 Dec 2015 14:55:11 +0100
Arnd Bergmann <a...@arndb.de> escreveu:
> On Thursday 17 December 2015 10:45:56 Mauro Carvalho Chehab wrote:
> > If I understood well, he's proposing to do is:
> >
> > struct media_v2_topology {
> > __u64 topology_version;
> >
> > __u32 num_entities;
> > __u32 num_interfaces;
> > __u32 num_pads;
> > __u32 num_links;
> >
> > __u64 ptr_entities;
> > __u64 ptr_interfaces;
> > __u64 ptr_pads;
> > __u64 ptr_links;
> > };
> >
> > The problem is that, if we latter need to extend it to add a new type
> > the extension will not be too nice. For example, I did some experimental
> > patches adding graph groups:
> >
>
> Can you clarify how the 'topology_version' is used here? Is that
> the version of the structure layout that decides how we interpret the
> rest, or is it a number that is runtime dependent?
No, topology_version is just a mononotonic counter that starts on 0
and it is incremented every time a graph object is added or removed.
It is meant to be used to track if the topology changes after a previous
call to this ioctl.
On existing media controller embedded device hardware, it should
always be zero, but on devices that allow dynamic hardware changes
(some embedded DTV hardware allows that - also on devices with FPGA,
with RISC CPUs or hot-pluggable devices) should use it to know if the
hardware got modified.
This is also needed on multi-function devices where different drivers
are used for each function. That's the case of au0828, with uses a
media driver for video, and the standard USB Audio Class driver for
audio. As the drivers are independent, the topology_version will
be zero when the first driver is loaded, but it will change during
at probe time on second driver. It will also be increased if one
of the drivers got unbind.
> If this is an API version, I think the answer can simply be to drop
> the topology_version field entirely, and use a new ioctl command code
> whenever the API changes. This is the preferred method anyway.
Regards,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
