On 27/09/2021 12:39, Laurent Pinchart wrote:
I'd like to propose a third approach (or at least I believe it's a third
one). I agree with Jacopo that the state structure should not have a
which field, that's a layering violation. The state is a state,
regardless of whether it holds TRY or ACTIVE data. What are the current
blockers that would prevent that ?
Oh, I agree with that too. I didn't add the 'which' field to state
because I thought it's good =). It is supposed to be temporary solution.
init_cfg() is the issue here.
It think I had these options:
- Change init_cfg() to take 'which' as a parameter
- Change init_cfg() implementations to not use 'which'
- Add new version for new drivers, init_cfg_state() or such, which
either gets the which as a parameter or doesn't use which.
- Add 'which' to state.
I chose the fourth one as it's a very small change, and can be removed
easily in the future when the underlying problem is solved.
However, I think .init_cfg() should be used to initialize *all* states,
both TRY and ACTIVE. That will simplify driver implementation (but
centralizing the initialization in a single place) and ensure that the
default value for the ACTIVE state always matches the default value for
the TRY state, which I think is important.
I agree.
That's the second option from you list above, right ?
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.
Tomi
