Hi Rui,

On Mon, Jan 04, 2021 at 01:45:11PM +0000, Rui Miguel Silva wrote:

Hi,
catching up with this thread.

On Mon, Jan 04, 2021 at 03:08:58PM +0200, Laurent Pinchart wrote:

quoted

On Mon, Jan 04, 2021 at 08:34:48AM -0300, Fabio Estevam wrote:

quoted

On Mon, Jan 4, 2021 at 3:05 AM Laurent Pinchart wrote:

quoted

That's not right, csi->is_csi2 is a flag that indicates if the
current input to the CSI comes from the CSI-2 receiver.

It looks like the i.MX6ULL is missing the MIPI CSI-2 receiver
and thus also the corresponding video mux. The WARN_ON() should
thus indeed by bypassed, but only for devices that don't have
the video mux. I wouldn't

Unlike i.MX7, i.MX6UL/i.MX6ULL do not have a MIPI CSI-2 IP block.

They only have a parallel CSI interface, and no video mux is
present.

So the csi->is_csi2 check I did seems correct, right?

I don't think so. csi->is_csi2 tells if the currently selected input
of the video mux is the CSI-2 receiver, not if there's a CSI-2
receiver present in the device. csi->is_csi2 should of course always
be false when there's no CSI-2 receiver, but it can be false when a
CSI-2 receiver is present and the currently selected input is the
parallel input.

Laurent is correct here. That flag indicates if CSI-2 is the selected
input for the video mux.

quoted

quoted

quoted

be surprised if other adaptations would be needed in the code.

I really only had the warp7 board which only had the csi2 as video mux
input, never got the chance to test it with a parallel input. And the
driver expects that we always have a mux. I was not even aware that an
imx6 would have the same csi ip.

but from the error outputs looks issues getting the format around the
imx7_csi_{try, get}_fmt.

Do you still have the hardware, would you be able to test a patch series
?

quoted

quoted

Yes, I found other paths that miss the csi->is_csi2 check too.

-- 
Regards,

Laurent Pinchart