On Tue, Sep 28, 2021 at 03:33:18PM +0300, Tomi Valkeinen wrote:
> 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'.
Jee ! Olen iloinen :-)
> 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?
I don't mind, I was going to propose it when reading the above.
--
Regards,
Laurent Pinchart
