drivers: video: allow allocation with a header preceding the buffer

[josuah]

Some protocols expect a header followed the buffer payload. Inserting a header at allocation time permits to have a single buffer including both the header and the payload in a continuous memory region as expected by some drivers, without requiring to memcpy() the header and payload every time.

Before:

vbuf
[                     ]
^.buffer              ^.buffer + .size

After:

vbuf
[          |                     ]
^.header   ^.buffer              ^.buffer + .size

[josuah]

I am not entirely happy with reinventing buffer management inside video.h, as this is something already solved at other places:

• https://docs.zephyrproject.org/latest/services/net_buf/index.html
• https://docs.zephyrproject.org/latest/services/rtio/index.html#memory-pools
• https://docs.zephyrproject.org/latest/kernel/data_structures/ring_buffers.html
• https://docs.zephyrproject.org/latest/kernel/memory_management/slabs.html
• https://docs.zephyrproject.org/latest/kernel/memory_management/sys_mem_blocks.html

This PR goal is mostly to expose the requirements of #76798.

[loicpoulain]

How are we supposed to know header size when doing allocation? Wouldn't make it sense to allocate the necessary size from the capture driver itself. We could have an internal head pointer and adjust both head and buffer (data/payload) pointer when via some sort of vbuf_reserve function in the driver? (similarly to Linux skb: https://docs.kernel.org/networking/skbuff.html).

[josuah]

Thank you for this feedback!

Looking at how the SKB API is used, the headroom is taken into account during the allocation (RSTN_ALIGN):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/renesas/rtsn.c#n363

		skb = netdev_alloc_skb(ndev, PKT_BUF_SZ + RTSN_ALIGN - 1);
		if (!skb)
			goto error;
		skb_reserve(skb, NET_IP_ALIGN);

If it is a global headroom_reserve API, this wastes a bit of memory in every buffer that did not use any headroom.
If it is a per-device headroom_reserve API, this mean the allocation becomes more complicated as each device must check the headroom required by the sink.

In https://github.com/zephyrproject-rtos/zephyr/pull/76798/files I will memcpy() the first USB packet (64 ~ 512 bytes max per frame) and migrate to a better API once introduced.

[josuah]

The workaround above works: the first packet is memcpy()-ed with the header. It does not look like this memcpy() is impactful, althrough this was not benchmarked. This could be come relevant again if wanting to pass large amount of metadata before a frame. Then the suggestions will be useful!