drivers: video: gc2145: Add support for YUV format.

[iabdalkader]

Can be used to get a fast grayscale image. Note enum resolutions is not needed at all, but I wanted to keep changes minimal.

[josuah]

The changes look ideal IMHO.

[iabdalkader]

@josuah

Is there a way to provide the memory pool for video_buffer_aligned_alloc or specify the video memory via conf or overlay? For example, to use SDRAM for buffers? I'm running out of memory and can't test any bigger frames.

[josuah]

I believe the way @LucasTambor wanted to solve this is through the use of "shared multi-heap":

CONFIG_ESP_SPIRAM -> CONFIG_SHARED_MULTI_HEAP -> CONFIG_MULTI_HEAP

And was integrated into the Video allocation API via CONFIG_VIDEO_BUFFER_USE_SHARED_MULTI_HEAP:

• drivers: video: Add SMH option for video buffer #76982

It's up to the user to use to configure it or not. If their platform supports it and they want to use a memory region with capabilities such as external/cacheable/non-cacheable (depends on what SMH supports) is now possible, otherwise if they do nothing it will use default sys_heap as it used to be.

Applied here:

zephyr/drivers/video/video_common.c

Line 54 in e4389a2

block->data = VIDEO_COMMON_HEAP_ALLOC(align, size, timeout);

[josuah]

The alternative would be to catch the video memory pool defined here in a board-specific linker script or custom linker script:

zephyr/drivers/video/video_common.c

Line 20 in e4389a2

K_HEAP_DEFINE(video_buffer_pool, CONFIG_VIDEO_BUFFER_POOL_SZ_MAX*CONFIG_VIDEO_BUFFER_POOL_NUM_MAX);

A bit more ad-hoc but could work too depending on the goals.
Maybe that would be a good time to look how that solution got solved on other subsystems and introduce some way to tell where implicitly allocated buffers go.

[iabdalkader]

@josuah I'll give the first option a try tomorrow and let you know how it goes. Thanks for the hint!

[iabdalkader]

@josuah I tried the shared multi-heap and it works fine. However, I think video_stm32_dcmi.c requires a small fix. Currently, it allocates its own static buffer in SRAM which overflows if CONFIG_VIDEO_BUFFER_POOL_SZ_MAX is increased (something you'd want to do after switching to SDRAM), and this buffer was never aligned, I think. Basically, we need to use VIDEO_COMMON_HEAP_ALLOC from video_common.c. Can I move this to video.h, or just duplicate it?
See: #84446

Also, display_stm32_ltdc.c does something similar by placing the frame buffer in SDRAM. I'm not sure how to get the remaining free SDRAM for the shared multi-heap and I couldn't find a config option to specify its size either. I understand the heap blocks are added at runtime, just not sure how to specify the SDRAM heap size.

[josuah]

Thank you for this new PR! I will pursue the discussion on that topic on #84446.