does it really make sense to support runtime pm when your imager takes around a second to be operational?
hmm. I can likely reduce that by using g_skip_frames
the more I look into this, the more I notice that I need s_stream support to move forward. I'm having a major problem with that though:
there are two ways to enable streaming: a) set a bit in an i2c register and it streams b) set another bit in another i2c register and actually start streaming when a particular gpio goes high
a) is quite obvious for s_stream but how does b) work with s_stream?
in particular s_stream must not change the gpio, because the gpio activates multiple components synchronously. s_stream must be called multiple times on multiple devices before the gpio can be raised
grohne: In case b the sensor could be powered on based on s_stream callback.
How is the gpio controlled currently?
you asked about how the frames are consumed and I replied "custom hardware". this all started entirely without any v4l2 infrastructure. I've converted the imager driver to v4l2 and left the rest as is for now
so now there is a userspace process that deals with a v4l2 subdev directly and that process also raises a gpio
how do I tell s_stream which of a) or b) it is supposed to do? it only accepts a boolean
Ok.
I think you could add a control to tell whether streaming is started using GPIO or STREAMON IOCTL.
And s_stream() would be called in both cases, it just would start streaming if the value of that control would indicate that. Otherwise it'd just power on the sensor.
How does this approach look like to you?
This way we could support both regular hardware (streaming control over I²C) and where a GPIO is used to start streamin.
Streaming, I mean.
yes please. do you have a more precise vision on that control?
Boolean control?
like s_ctrl V4L2_CID_$something?
It could be called e.g. V4L2_CID_STREAMING_TRIGGER_EXTERNAL.
I think it'd be nice to standardise it since I don't think your hardware is the only one where this could be used.
I've seen it actually elsewhere but no-one has needed it before. :-)
I think I can tell you that a lot of people need this.
basically anyone who is doing stereo vision will need it
Or at least they have never expressed that need.
in any case, that works for me. :)
Well, in many cases, yes.
We don't really have stereo imaging implementations in upstream.
is it ok to add such a cid as a separate patch with no users?
It needs to be a separate patch, yes.
i.e. submit the user of such a cid later than the actual cid?
or should that go into one patch series?
The same series would be the best.
What has happened in the past was that interfaces were added but no-one used them in the end.
It's also good to be able to review the driver using the control at the same time.
will do
I've just grepped throug V4L2_CIDs and didn't find anything remotely relevant
Some sensors also can also output the streamon trigger signal.
Perhaps the control should be considered this in mind.
I don't think it exists at the moment.
I think mt9m024 can do that
Control and the documentation should be in the same patch.
It should go here: Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst
ah I was about to ask whether it should be sorted into V4L2_CTRL_CLASS_CAMERA
you implicitly answered
:-)
I think I've got some things to do now. thank you for all the steering
(now as in "next week" though)
You're welcome!
I think that also explains why I didn't have any s_stream :)