Am Freitag, dem 12.11.2021 um 15:49 +0100 schrieb Martin Kepplinger:

Am 12. November 2021 13:40:43 MEZ schrieb Alexander Stein
[off-list ref]:

quoted

Hello Martin,

Am Freitag, dem 12.11.2021 um 12:23 +0100 schrieb Martin
Kepplinger:

quoted

hi Laurent and all who it may concern,

Ever since I switches to using imx7-media-csi on imx8mq I have
seen a
bug that hangs /freezes the system so that I can't really save a
trace
or get logs for it. It happens not every time when starting
streaming,
but sometimes - when starting to stream frames.

It kind of looks like a lock not released or something similar,
but
some race condition might happen since it's happening every 2 to
10
times.

For me, when it fails, it fails the first time when starting to
stream
after rebooting. If it succeeds that first time, it continues to
succeed, until I reboot.

When I read your description I was immediately reminded to this
post on
NXP forums [1].
I do not know if this is what is happening to you, but it sounds
somewhat similar. There is also an errata in post [2] describing
some
backgrounds. Later posts also describe that apparently only CSI
port 1
is affected, but CSI port 2 is not.
Do you have the possibility to test CSI port 2?

yes but I can only say that csi port 2 behaves better while I have
seen a lockup there too. That too matches your links' issue
description. I dont have logs from port 2 yet.

Thanks a lot, there's at least something new to test I think. Let's
see whether a kernel thread would work instead of an m4 program.

But why haven't I ever seen the problem on the mx6s_capture nxp
driver? That doesn't fit the picture yet for me.

quoted

Best regards,
Alexander

[1]
https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1218063
[2]
https://community.nxp.com/t5/i-MX-Processors/IMX8MQ-MIPI-CSI2-Base-address-switching-change-error/m-p/1216509/highlight/true#M167970

this seems to be fixed by
https://lore.kernel.org/linux-media/20211117092710.3084034-1-martin.kepplinger@puri.sm/T/#t (local)

the issue described in the nxp forums should be taken care of by the
underrun (or called "discard" in the nxp driver) buffer in the driver.

thank you!

                                 martin