On Thu, 2019-06-27 at 15:12 -0700, Steve Longerbeam wrote: > > On 6/27/19 5:56 AM, Philipp Zabel wrote: > > Hi Fabio, > > > > On Thu, 2019-06-27 at 09:38 -0300, Fabio Estevam wrote: > > > Hi Philipp, > > > > > > On Thu, Jun 27, 2019 at 5:43 AM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: > > > > > > > Are there any visual artifacts in the first frame(s) in this case? > > > > > > I do not observe visual artifacts when running gst-launch-1.0 v4l2src ! kmssink > > > > > > > > So in my opinion the next version of this patch should make LP-11 > > > > > timeout a warning only, but keep the error return on clock lane timeouts. > > > > > > > > I agree. > > > > > > Here is a reworked version of Ezequiel's patch as per the suggestions: > > > http://code.bulix.org/g5qap5-780475 > > > > > > Does this one look good? > > > > Limiting the change to wait_stopstate is fine, the actual message > > makes assumptions that could be misleading. How about: > > > > "Timeout waiting for LP-11 state on all active lanes. > > This is most likely caused by a bug in the sensor driver. > > Capture might fail or contain visual artifacts." > > Yes I agree that is more descriptive, if a bit wordy for a kernel error > message. Haha, yes, I remember that thought crossing my mind. > I think it could be reduced, something like: > > "LP-11 wait timeout on all lanes, likely a sensor driver bug, expect > capture failures." Much better, thanks. regards Philipp
