Hi Laurent,
On 28/09/2021 10:52, Laurent Pinchart wrote:
Hi Tomi,
On Tue, Sep 28, 2021 at 08:02:18AM +0300, Tomi Valkeinen wrote:
On 27/09/2021 04:45, Laurent Pinchart wrote:
On Mon, Aug 30, 2021 at 02:00:46PM +0300, Tomi Valkeinen wrote:
All suitable subdev ops are now passed either the TRY or the ACTIVE
state by the v4l2 core. However, other subdrivers can still call the ops
passing NULL as the state, implying the active case.
Thus all subdev drivers supporting active state need to handle the NULL
state case.
Do they ? Can't we mandate that the callers pass the correct state ? Do
you think that would make the transition too difficult ?
That would limit the use of the new drivers. E.g. the sensor driver I'm
using works fine with CAL & co. without handling the NULL, but then the
sensor driver couldn't be used with "old" drivers.
I'm tempted to say that would be a good thing as it would accelerate the
transition :-)
I tested this, and as expected the drivers I'm using work fine without
the "validate" version. From that perspective I'm fine with dropping the
whole "validate" concept, and just require state to be valid for the new
multiplexed-streams-enabled drivers.
But the thing is, all the drivers I use are new, and not used in other
hardware platforms or configurations. However, if someone ports an
existing driver to multiplexed streams, either he has to be sure no
other setup is using that driver, or add some kind of "validate" system.
Maybe that's still ok. I don't expect people to be rushing to port the
drivers to multiplexed streams =).
So if there are no complaints, I'll drop the validate functions. And we
can always add them back later for the few drivers that need them, if
the plan goes bad...
Tomi
