Introduce a video_get_format_index() utility to help finding a caps
entry out of a given format. Introduce several utilities to seek and
apply frame intervals.
Signed-off-by: Josuah Demangeon <me@josuah.net>
This commit enables the user to choose whether to
allocate the video buffer from the video heap pool
or use a memory region with specific extra capabilities,
such as being cacheable/non-cacheable or using external
memory.
Signed-off-by: Lucas Tamborrino <lucas.tamborrino@espressif.com>
Zephyr drivers have typically one log level defined per class. The video
drivers were making exception. This adds the missing log level for video
drivers.
Since all headers had to be modified, this also:
- Update the log initialization to the new syntax from 5e34681
- Sort the #include list to something like #41543
Signed-off-by: Josuah Demangeon <me@josuah.net>
For some hardwares, it is very common that some aligment on the allocated
memory is required. For example, the PxP and eLCDIF of NXP require aligned
buffers so that their performances can be optimal.
Add a new video_buffer_aligned_alloc() API for these needs.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a missing keyword in a variable declaration and correct the type
in a missed declaration. Also use a more appropriate upper bound in a
loop.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Use the core k_heap API pervasively within our tree instead of the
z_mem_pool wrapper that provided compatibility with the older mempool
implementation.
Almost all of this is straightforward swapping of one alloc/free call
for another. In a few cases where code was holding onto an old-style
"mem_block" a local compatibility struct with a single field has been
swapped in to keep the invasiveness of the changes down.
Note that not all the relevant changes in this patch have in-tree test
coverage, though I validated that it all builds.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
k_mem_pool_malloc reserves some space for block descriptor at the start
of the data block, causing misalignement of returned video buffer.
In our context we want to return a video buffer with aligment matching
the video buffer poll alignment config. Fix that by using the simpler
k_mem_pool_alloc function.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
