The current video drivers did not allow VIDEO_EP_ALL to be selected,
as used by video_stream_stop().
This adds the VIDEO_EP_ALL to each video driver that filtered endpoints.
Signed-off-by: Josuah Demangeon <me@josuah.net>
The frame event callback unconditionally copies into the enqueued video
buffer. The driver only supports fixed length frames, so reject enqueued
buffers that are not large enough to prevent invalid memory access.
Signed-off-by: Brett Witherspoon <brett@witherspoon.engineering>
Introduce driver for ov7670 camera, supporting QCIF,QVGA,CIF, and VGA
resolution in YUV and RGB mode.
Support was verified on the FRDM-MCXN947, using the SmartDMA camera
engine, which is enabled in the following PR:
https://github.com/zephyrproject-rtos/zephyr/pull/72827
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
On i.MX RT11XX which has MIPI CSI-2 Rx, image data from the camera sensor
after passing through the camera pipeline (MIPI CSI-2 Rx --> Video Mux -->
CSI) will be implicitly converted to a 32-bits pixel formats. For example,
an input in RGB565 / YUYV (2-bytes format) will become an XRGB32 / XYUV32
(4-bytes format), respectively. Make changes to support this.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Add driver to support NXP MIPI CSI-2 Rx which is a MIPI CSI-2 receiver
connecting a camera sensor to the NXP CSI. This IP is present in the
i.MX RT11XX series.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The CSI can connect to either a camera sensor (as on i.MX RT10xx) or
a MIPI CSI-2 receiver (as on i.MX RT11xx). To be generic, change the
naming from sensor to source.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The CSI should always propagate the get_fmt request down to the sensor.
It should not return a format by it own unless it contains a test
pattern generator inside it.
The problem with the legacy code is that this code snippet is never
reached if the sensor could return a format. In case the sensor failed
to return a format, these codes are reached but the returned format
makes no sense and its value was not initialized.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The HAS_MCUX_CSI (as well as all the HAS_MCUX_XXX) config was obsolete
and has been replaced by the DT_HAS_NXP_IMX_CSI_ENABLED (i.e.
DT_HAS_XXX_ENABLED). Drop it as well as all the dependencies on it.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
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>
Currently, the driver supports only VGA resolution while 480x272 is
needed to match with the display resolution on i.MX RT10XX family.
Also, the current framerate is very low, about 3-4 fps without doing
anything else with the image buffers (just discarding them).
Rework the driver to address the low framerate issue as well as to add
support for 480x272 and 1280x720 resolutions.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Add support for XRGB32 pixel format as this is useful to test camera
and display drivers on i.MX RT11xx
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The stream_start() callback needs to return 0 for success. However, to
indicate work has been successfully scheduled, k_work_schedule() could
return either 0 (already scheduled) or 1 (newly scheduled).
Due to this issue, the sw_generator could not start streaming. Fix it.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Set a dedicated priority for the video_mcux_csi instead of using the
default kernel device init priority. This allows initializing the device
in a sequence that matches the devicetree hirearchy compared to mt9m114.
Fixes the error:
ERROR: /soc/csi@402bc000 POST_KERNEL 50 <
/soc/i2c@403f0000/mt9m114@48 POST_KERNEL 60
found using:
$ west build -p -b mimxrt1064_evk samples/subsys/video/capture \
-DCONFIG_CHECK_INIT_PRIORITIES=y
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
video_mcux_csi_init, which setups the CSI pins (i.e: calls
pinctrl_apply_state) was called after mt9m114_init which tries to do i2c
communication with the camera to read the chip id. But since one of the
CSI pins is the camera master clock, doing things in this order won't
work. This PR inverts the order in which the devices are initialized.
Signed-off-by: Michele Balistreri <michele@bitgamma.com>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
Update video drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol
to expose the driver and enable it by default based on devicetree.
Signed-off-by: Kumar Gala <galak@kernel.org>
Replace sensor_label property in devicetree with just a sensor phandle
property. This is more generic and allows driver to use DEVICE_DT_GET
instead of device_get_binding.
Signed-off-by: Kumar Gala <galak@kernel.org>
When we moved to gpio_dt_spec forgot to remove the older
fields used for gpio related access. Remove them as they
are used by the driver anymore.
Signed-off-by: Kumar Gala <galak@kernel.org>
Updates the API and types to match updated I2C terminology. Replaces master
with controller and slave with target.
Updates all drivers to match the changed macros, types, and API signatures.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
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>
This adds the driver for Omnivision OV2640 image sensor.
The driver provides support for 10 different resolutions in range from
160x120 to 1600x1200 in both JPEG and RGB565 pixel formats. There are
also mutliple configuration options, e.g. hflip, vflip, saturation and
brightness control.
Signed-off-by: Robert Szczepanski <rszczepanski@antmicro.com>
