On 28/09/2021 08:14, Tomi Valkeinen wrote:
Yes. I'm not 100% sure yet if it's possible to get rid of which from
init_cfg, but I'll try it out.
As ACTIVE state support is opt-in, it seems to me that we won't need to
mass-fix drivers as part of this series if we go for this option. Am I
Yes, I think so. I'll be wiser after I've worked on this a bit =). I
think the routing needs the biggest change, as the routing table
contains 'which'. But routing won't affect the current drivers.
However, 'which' is quite ingrained to v4l2, I won't be too surprised if
I keep finding new 'whiches' while removing it from the init_cfg call
paths.
It was rather easy to get rid of 'which'. I now have
v4l2_subdev_routing, which is the struct used in the uAPI:
struct v4l2_subdev_routing {
__u32 which;
__u64 routes;
__u32 num_routes;
__u32 reserved[5];
};
Then I have v4l2_subdev_krouting, which is used when calling the subdev
set_routing op:
struct v4l2_subdev_krouting {
u32 which;
struct v4l2_subdev_routing_table table;
};
And I have v4l2_subdev_routing_table, which is used in the various
helper functions, and stored in the state:
struct v4l2_subdev_routing_table {
unsigned int num_routes;
struct v4l2_subdev_route *routes;
};
As the only use of v4l2_subdev_krouting is when calling the subdev's
set_routing, I think we should just drop it and pass 'which' as a
parameter to subdev's set_routing(). That is a different style compared
to the other ops, which have the 'which' inside the passed struct.
Any opinions?
Tomi
