Jacopo Mondi <jacopo@xxxxxxxxxx> writes: >> This is BTW completely orthogonal to the -EBUSY on set_fmt(). The >> effects will be exactly the same if the e.g. geometry changes come when >> the sensor is not streaming. >> > > No, this isn't true. Your s_fmt() implementation stops then restart the > stream. It has an undocumented side effect and will cause undefined > behaviour. It will cause *at*most* a corrupted frame. On a MIPI link. That's right. Such a corrupted frame will *at*most* cause some transient IO error - it must not cause anything serious, because corrupted frames on MIPI can happen for multiple reasons, some of which simply cannot be avoided. BTW I will see if it's actually the case - chances are, there is no corruption, but I tested it years ago and haven't yet checked my notes. In fact those set_fmt() in other drivers may - or may not - cause corrupted frames just the same. > If your s_fmt() has to stop and restart streaming to take effect, > it means userspace should instead stop the stream, change > the format where opportune in the pipeline, and then restart the > stream. Maybe. This is a sensor driver - not userspace. If the userspace uses it as a part of "frame grabber", it will certainly do exactly that (nothing else would make sense in practice). Unfortunately this all will have to wait a bit, so thanks for your help, expect a new patch in few weeks. -- Krzysztof "Chris" Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa
