video: gc2145/stm32_dcmi support Crop and basic DMA recovery #97491
Conversation
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
avolmat-st,
djiatsaf-st,
erwango,
etienne-lms,
gautierg-st,
josuah,
loicpoulain,
marwaiehm-st,
mathieuchopstm and
ngphibang
There was a problem hiding this comment.
Thanks @KurtE for this PR. This is roughly good to me, some comments, small things to cleanup but nothing really big.
Only the last comment about the dcmi_dma_callback needs to be checked more. I recall seeing a potential issue before in the dma_stm32 code so I check this in parallel of your update of this PR.
There was a problem hiding this comment.
Reword 1st commit message to remove reference to video_stm32_dcmi, the cam driver could be used with any cam controller.
Reword 3rd commit message to remove the unnecessary talk about the other PR, and to have a message that actually describes the change and why it's needed.
Implements the set_selection and get_selection APIs,
if forwarded to it by a camera controller.
It uses the new messages
to allow you to set a crop window on top of the
current format window. It also then allows you
to move this crop window around in the frame
window.
With this driver I also updated it to allow any resolution
from the displays min to max limits.
static const struct video_format_cap fmts[] = {
GC2145_VIDEO_FORMAT_CAP_HL(128, 1600, 128, 1200,
VIDEO_PIX_FMT_RGB565),
GC2145_VIDEO_FORMAT_CAP_HL(128, 1600, 128, 1200,
VIDEO_PIX_FMT_YUYV),
When the resolution is set, it computes the scale factor.
Using the set_selection(VIDEO_SEL_TGT_CROP) allows you
define a crop window within the format window.
It clamps the ratio to a max of 3 as some other
drivers limit it saying it helps with frame rates.
Signed-off-by: Kurt Eckhardt <[email protected]>
Forward the get_selection and set_selection APIs to the camera objects, to allow some of the selections to be supported at the camera level. Signed-off-by: Kurt Eckhardt <[email protected]>
KurtE
force-pushed
the
camera_snapshot_minus_snap
branch
from
4e37920 to
e21d91f
Compare
|
Twister failings... Is this another case where I should rebase again? |
You can see what is failing & why here |
On several boards, such as the Arduino Giga and Portenta H7, they are often times setup with their camera buffers and potentially video buffers in SDRam. This can lead to a significant number of DMA errors, which currently stops the camera from returning any additional frames. This Pull request tries to recover from a subset of them, by stopping the HAL DCMI and then restart it. Signed-off-by: Kurt Eckhardt <[email protected]>
KurtE
force-pushed
the
camera_snapshot_minus_snap
branch
from
e21d91f to
d3244ca
Compare
|
6 participants
Added support to video_stm32_dcmi for the new
set and get selection. These implementations simply forward the message to the underlying
camera object if they support these messages.
GC2145 was updated first to support setting a crop window, using the order
try out these changes. The camera now allows me to follow the call order
of calls that @josuah mentioned in another pr/issue.
With this driver I also updated it to allow more or less any video resolution:
{
.pixelformat = format, .width_min = width_l, .width_max = width_h,
.height_min = height_l, .height_max = height_h, .width_step = 0, .height_step = 0,
}
static const struct video_format_cap fmts[] = {
GC2145_VIDEO_FORMAT_CAP_HL(128, 1600, 128, 1200, VIDEO_PIX_FMT_RGB565),
GC2145_VIDEO_FORMAT_CAP_HL(128, 1600, 128, 1200, VIDEO_PIX_FMT_YUYV),
When resolution is set, it computes the scale factor. If you then later call set_crop, the same code is
used except it uses the ratios computed from the set_resolution.
In addition, I pulled in the minimal DCMI changes, that allow the camera code to recover after some DMA
errors.
This is a partial replacement for #93797 It does not support the SNAPSHOT mode that is part of that PR, but decided
it might be simpler and easier to understand if this was done instead in smaller steps.