Hi. 2009/2/4 Dominic Curran <dcurran@xxxxxx>: > The device has only one read register which contains a single BUSY bit. > For large relative lens movements the device can be busy for sometime and we need > to know when the lens has stopped moving. > > My question is what is the most appropriate mechanism to read the BUSY bit ? > > Currently the driver uses the VIDIOC_G_CTRL ioctl + V4L2_CID_FOCUS_RELATIVE ctrl > ID to return the BUSY bit. Is this acceptable ? [...] > A 3rd solution is to read the BUSY bit everytime after a write and not return > until device is ready. However this adds extra time to the operation > (particularly for small lens moves) and I would like the user to be in change of > when the reads of BUSY bit occur. And what about waiting for not BUSY at the *beginning* of the next lens adjustment if the previous one hasn't finished yet? This could be combined with either a polling interface or a sync style interface (wait for not BUSY function) for the case in which the user wants to actually be sure that the lens got up to its target state. Best regards, JJ. -- Dream small if success is enough for you; dream big if you need to change the world. -- 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
