Introduce a new video device structure representing a device in a
video pipeline. Each video device embeds a pointer to its "source"
device and other "video" characteristics.
This structure give the video framework an access to all video features
of the device and a hierachical view of the video pipeline that the
device belongs to.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The video_stream_start/stop() APIs are counter-symetric and have
the same function signature. Also, the implementation logic for
those driver APIs is generally the same. Merge them to save memory
and code lines.
For the sake of simplicity, still keep the user APIs to preserve
backward compatibility with downstream applications.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
This uses Linux V4L2 controls as a reference to give names to the
CIDs. Apply the renaming down to the drivers that use them.
Signed-off-by: Josuah Demangeon <me@josuah.net>
Remove the unnecessary video-controls header included in video.h.
Drivers, applications should explicitly include it when needed.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Color bar is one type of test patterns. Rename it to
VIDEO_CID_CAMERA_TEST_PATTERN to be more generic.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.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>
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>
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>
