Improve NXP CSI and MIPI_CSI2Rx drivers

[ngphibang]

This PR improves the NXP's csi and mipi_csi2_rx drivers including

• Some minor fixes & optimization
• Support for changing frame rate
• Fixed the chicken-egg issue on NXP i.MX RT10xx

Fixes #80304

This PR depends on #74415 and #72254, also relates to #76144

[trunghieulenxp]

Rebase because the PR #73009 is merged.

[ngphibang]

@danieldegrasse Regarding the commit "drivers: video: csi: Fix start / stop issue", your points are almost right. To summerize:

• After stopping, users are expected to re-enqueue the buffers before restart streaming
• However, when stopping, the SDK CSI driver puts all the active buffers into the input (empty) queue with expect that user can start again right away as can be seen here
• While the Zephyr CSI driver puts all the buffers in the input queue into the output queue as can be seen here
• So, to fix the issue with these conflict behaviors, I think we need to call CSI_STOP() and disable interrupts directly without passing by CSI_TransferStop() as you said. The input and output queues in the Zephyr CSI driver need to be clean too.

Given the strict timeline approaching and to facilitate the review, we removed this commit from the PR and wait for next time to submit it.

[danieldegrasse]

@danieldegrasse Regarding the commit "drivers: video: csi: Fix start / stop issue", your points are almost right. To summerize:

* After stopping, users are expected to re-enqueue the buffers before restart streaming

* However, when stopping, the SDK CSI driver puts all the active buffers into the input (empty) queue with expect that user can start again right away as can be seen [here](https://github.com/zephyrproject-rtos/hal_nxp/blob/99570ee6fa32a9ab413b8ee9c0226cda26f6a2ae/mcux/mcux-sdk/drivers/csi/fsl_csi.c#L705)

* While the Zephyr CSI driver puts all the buffers in the input queue into the output queue as can be seen [here](https://github.com/zephyrproject-rtos/zephyr/blob/aefda52e42b599592dcfbcbd359aa8dd6e908994/drivers/video/video_mcux_csi.c#L271)

* So, to fix the issue with these conflict behaviors, I think we need to call CSI_STOP() and disable interrupts directly without passing by CSI_TransferStop() as you said. The input and output queues in the Zephyr CSI driver need to be clean too.

Given the strict timeline approaching and to facilitate the review, we removed this commit from the PR and wait for next time to submit it.

Reading the video driver documentation, I think the behavior for video_mcux_csi_flush is correct- if the user opts to cancel buffer processing, then queued buffers are supposed to be moved through the queue without being processed (like the implementation does)

There isn't clear documentation on how video_stream_stop is supposed to function regarding input buffers. We could either:

• discard all buffers in the input queue, and require user to re-queue them
• keep buffers queued in the input queue, and when the stream is restarted use those buffers

@loicpoulain do you know which behavior is correct?

I do not think we should flush or modify the output buffer queue when the stream is stopped.

Request addressed

[ngphibang]

keep buffers queued in the input queue, and when the stream is restarted use those buffers

=> The CSI needs at least 2 buffers to be able to start. Remaining buffers in the input queue may be insufficient. That's why users need to re-queue buffer (option 1).

I do not think we should flush or modify the output buffer queue when the stream is stopped.

=> If users re-queue buffers (of course they will not allocate new buffers but re-use the ones in the buffer pool). We need to clean the output queue unless buffers will be present on both input and output queues.

[danieldegrasse]

=> The CSI needs at least 2 buffers to be able to start. Remaining buffers in the input queue may be insufficient. That's why users need to re-queue buffer (option 1).

Sorry, I think I might have been unclear. My understanding is that user might interact with the video API like so:

• Queue buffer A
• Queue buffer B
• Queue buffer C
• start CSI stream
• dequeue processed buffer A
• stop CSI stream

At this point, if the CSI has processed buffer B we should expect that buffer to be in the output queue, and if the user tries to dequeue a video buffer they will get buffer B.

Video buffer C is where I am not sure. I think that the buffer should remain in the input queue, so that if the user then does something like so:

• Queue buffer A
• Queue buffer B
• dequeue buffer

They would receive buffer C. However, I'm not sure if this is correct, or if we should be clearing the input queue so that the user now would receive buffer A when they run the dequeue operation.

Does this help clarify my question here?

[ngphibang]

Video buffer C is where I am not sure. I think that the buffer should remain in the input queue, so that if the user then does something like so:

Queue buffer A
Queue buffer B
dequeue buffer
They would receive buffer C. However, I'm not sure if this is correct, or if we should be clearing the input queue so that the user now would receive buffer A when they run the dequeue operation.

Yes, buffer C is in the input queue. But, sorry I don't really get your idea behind when raising these points (?) So, let me summerize what's going on in the application:

• allocate an array of 2 buffers (most of the cases the min_buffer_count = 2)
• enqueue 2 buffers (step X)
• start stream
• In an infinite loop, doing:
  => dequeue a buffer
  => do something with the buffer
  => re-enqueue the buffer

At this point, user can "stop stream" and this can happen at any step in the loop. So, the questions are:

• What should the (CSI) driver is supposed to do when stopping so that user can restart again ?
• What should user be expected to do to restart ?

My points are

• A restart should be treated as a "new" start. That means users will enqueue the 2 buffers (jump to step X) and call "start stream". For the question 2, users do not need to know which buffers are in the input or output queue and do not need to dequeue all the buffers remaining in the output queue.
• Currently, at the stopping step, when flushing, the Zephyr CSI driver moves all the buffers in the input queue into the output queue. A (little) advantage of this is users can get the remaining processed buffer (usually just 1 buffer, the last frame). But the drawback is that users need to dequeue all the buffers in the output queue to empty this queue before enqueuing them again into the input queue (while he/she may not do this). That's why I said that we need to modify this to just clean up the input and output queue, so that users can re-enqueue the buffers without any problems.

A typical example of capturing application can be found here in Linux. They don't really do a restart but we can suppose that to restart, just call start_capturing() again. And you can see the start_capturing() function including the enqueuing buffer steps as I mentionned above.

        open_device();
        init_device();
        start_capturing();
        mainloop();
        stop_capturing();
=> can restart by calling start_capturing(); here