Hi Laurent,
I am looking at a case where the sensor may stop delivering data, at
which point I want to do a STREAMOFF. In this case, the STREAMOFF takes
2s because of the wait_event_timeout() in ccdc_disable(). This wait
waits for ccdc->stopping to be CCDC_STOP_FINISHED, which happens in two
stages (only 2 because LSC is always LSC_STATE_STOPPED for me),
1. in VD1 because CCDC_STOP_REQUEST has been set by ccdc_disable()
2. in VD0 after CCDC_STOP_REQUEST had happened in VD1.
But because the data has already stopped coming from the sensor, when I
do STREAMOFF, I'm no longer getting VD1/0, so ccdc->stopping will never
become CCDC_STOP_FINISHED, and the wait_event_timeout() has to run its
course of 2 seconds. This doesn't change the control flow in
ccdc_disable(), except to print a warning "CCDC stop timeout!" and
return -ETIMEDOUT to ccdc_set_stream(), which in turn returns that as
its return value. But this value is ignored by its caller,
isp_pipeline_disable(). It looks to me, then, like the only difference
between timing out and not timing out is getting the warning message.
omap3isp_sbl_disble() is called the same in both cases.
Q: Is there another reason for the wait & timeout? Is there some
functional difference between timing out and not timing out? 2 seconds
sounds fairly arbitrary, are there constraints on that, or could I at
least lower it to speed up STREAMOFF?
I know that normally the data wouldn't stop coming from the sensor until
after the CCDC is disabled, when the sensor's s_stream(0) is called.
But in this case the sensor is being driven externally, and I'm trying
to react to that.
thanks,
Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
