drivers: video: Add support for arducam mega #66994

ArduCAM · 2023-12-25T09:35:18Z

The Arducam mega is an low power, rolling shutter camera, support connect one or more cameras any Microcontroller. It provides high-quality image capture and processing capabilities, making it highly suitable for various application fields, including machine vision, image recognition, and robotics, among others.

This commit adds arducam mega driver and bindings file.

github-actions · 2023-12-25T09:35:53Z

Hello @ArduCAM, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

drivers/video/Kconfig.arducam_mega

bjarki-andreasen · 2023-12-25T11:48:00Z

Hi, the zephyr project uses the Apache 2.0 license See, with exceptions for code imported from other projects, like this example but it seems this PR is written specifically for Zephyr, could you update the PR to use the Apache 2.0 license?

bjarki-andreasen

Initial impressions are good :)

drivers/video/arducam_mega.c

loicpoulain · 2023-12-26T10:56:03Z

drivers/video/arducam_mega.c

+
+#define DT_DRV_COMPAT arducam_mega
+
+#include <zephyr/drivers/video/arducam_mega.h>


Why do you need an header file? as far as I see everything can be in the C file.

@loicpoulain
Thank you for your detail check.
Due to our arducam mega driver need some specific controls and other parameters and we need provide them to user.
We have not see them in the video.h file. So we add a arducam_mega.h file. If not, users can't control our mega's full features.

Ok, but look like some of them, like exposure, brightness, etc, are quite common for camera, so it would be worth to add new generic CId for them, instead of having custom ones for each vendor. For sure that new control values should be in known device-agnostic unit like us or %..

@loicpoulain
Hello, thanks for your fantastic sugguestions. In fact， in the video-controls.h file there are exist some common camera controls, and we have use it，we can add some other common controls（such as exposure mode） to video-controls.h and send you a new PR.
But，we have some specific control just used for arducam mega. so we can't make sure all controls are common.
Do you think so?

Yes that's fine, you can also have private controls. But it makes sense to make the generic ones common.

@loicpoulain
OK, I have modified it.

loicpoulain · 2023-12-26T10:56:49Z

Hello, could you please rebase and squash.

ArduCAM · 2024-01-02T01:30:53Z

@loicpoulain
Hi, I have rebase and squash the PR, Does it have other issues?

ArduCAM · 2024-01-02T02:08:59Z

@galak
Hello,
Do you think does arducam mega driver need any other changes?

bjarki-andreasen · 2024-01-02T06:17:01Z

You still need to use the Apache 2.0 license, and you have a few CI issues to fix before this can be merged :)

ArduCAM · 2024-01-04T00:30:36Z

@bjarki-trackunit
Thank you very much for your detail check. Have modified them.

dts/bindings/vendor-prefixes.txt

include/zephyr/drivers/video/arducam_mega.h

drivers/video/arducam_mega.c

dismissing my review as comments to date re: typos etc have been addressed but I lack the domain knowledge to provide an actual +1

loicpoulain · 2024-01-10T08:37:45Z

include/zephyr/drivers/video-controls.h

+#define VIDEO_CTRL_CLASS_CAMERA  0x00010000 /**< Camera class controls */
+#define VIDEO_CTRL_CLASS_MPEG    0x00020000 /**< MPEG-compression controls */
+#define VIDEO_CTRL_CLASS_JPEG    0x00030000 /**< JPEG-compression controls */
+#define VIDEO_CTRL_CLASS_VENDOR  0xFFFF0000 /**< Vendor-specific class controls */
 /**


No functional change above?

Can you move generic video changes to dedicated commit?

@loicpoulain OK， I have send a new PR

bjarki-andreasen

My comments have been addressed :)

kartben · 2024-01-10T09:08:35Z

@ArduCAM just curious if you'd be interested in contributing a code sample as a follow-up pull request? It would be really great to have a sample combining video and display APIs to actually display captured images on an LCD display. A sample saving captured image to file system would also be nice :) Thanks again for this PR, and thanks in advance if you happen to be interested in adding code samples :)

loicpoulain · 2024-05-20T17:20:03Z

@ArduCAM looks quite ok, I understand you have a custom sample to show off all the camera features. But could you confirm or test that the driver also works with the simple video capture sample?

ArduCAM · 2024-05-21T02:58:18Z

@ArduCAM looks quite ok, I understand you have a custom sample to show off all the camera features. But could you confirm or test that the driver also works with the simple video capture sample?

Thanks for your reply. I will test it and reply you later.

ArduCAM · 2024-05-22T01:46:42Z

@ArduCAM looks quite ok, I understand you have a custom sample to show off all the camera features. But could you confirm or test that the driver also works with the simple video capture sample?

@loicpoulain
Hello, I have some questions about the use of video capture. From the https://docs.zephyrproject.org/latest/samples/subsys/video/capture/README.html link，
I think the capture sample is used for testing capture device ( such as camera) basic functions Using video API.
That's great. But the demo in the main branch is used on mimxrt1064_evk as traget platform. If other platform, We have to modify the capture demo. Or I will prepare another capture demo and test API function?

Add some common camera's control: VIDEO_CID_CAMERA_EXPOSURE_AUTO, VIDEO_CID_CAMERA_GAIN_AUTO, VIDEO_CID_CAMERA_WHITE_BAL_AUTO, VIDEO_CID_JPEG_COMPRESSION_QUALITY Signed-off-by: Lee Jackson <[email protected]>

Adding frame length and fragmented frame status to indicate certain information about the frame when the video buffer is smaller than the frame length. Signed-off-by: Lee Jackson <[email protected]>

ArduCAM · 2024-05-22T06:11:59Z

@ArduCAM looks quite ok, I understand you have a custom sample to show off all the camera features. But could you confirm or test that the driver also works with the simple video capture sample?

@loicpoulain Have tested the capture using the samples/subsys/video/capture code. and do some necessary modification in order to fit mega spi camera.

/*
 * Copyright (c) 2019 Linaro Limited
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/device.h>

#include <zephyr/drivers/video.h>

#define LOG_LEVEL CONFIG_LOG_DEFAULT_LEVEL
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(main);

#define VIDEO_DEV_SW "VIDEO_SW_GENERATOR"

int main(void)
{
	struct video_buffer *buffers[2], *vbuf;
	struct video_format fmt;
	struct video_caps caps;
	const struct device *video;
	unsigned int frame = 0;
	size_t bsize;
	size_t fsize;
	int i = 0;

	/* Default to software video pattern generator */
	video = device_get_binding(VIDEO_DEV_SW);
	if (video == NULL) {
		LOG_ERR("Video device %s not found", VIDEO_DEV_SW);
		return 0;
	}

	/* But would be better to use a real video device if any */
#if defined(CONFIG_VIDEO_MCUX_CSI)
	const struct device *const dev = DEVICE_DT_GET_ONE(nxp_imx_csi);

	if (!device_is_ready(dev)) {
		LOG_ERR("%s: device not ready.\n", dev->name);
		return 0;
	}

	video = dev;
#elif defined(CONFIG_VIDEO_ARDUCAM_MEGA)
	const struct device *const dev = DEVICE_DT_GET(DT_NODELABEL(arducam_mega0));

	if (!device_is_ready(dev)) {
		LOG_ERR("%s: device not ready.\n", dev->name);
		return 0;
	}
	video = dev;
	
#endif

	printk("- Device name: %s\n", video->name);

	/* Get capabilities */
	if (video_get_caps(video, VIDEO_EP_OUT, &caps)) {
		LOG_ERR("Unable to retrieve video capabilities");
		return 0;
	}

	printk("- Capabilities:\n");
	while (caps.format_caps[i].pixelformat) {
		const struct video_format_cap *fcap = &caps.format_caps[i];
		/* fourcc to string */
		printk("  %c%c%c%c width [%u; %u; %u] height [%u; %u; %u]\n",
		       (char)fcap->pixelformat,
		       (char)(fcap->pixelformat >> 8),
		       (char)(fcap->pixelformat >> 16),
		       (char)(fcap->pixelformat >> 24),
		       fcap->width_min, fcap->width_max, fcap->width_step,
		       fcap->height_min, fcap->height_max, fcap->height_step);
		i++;
	}

	/* Get default/native format */
	if (video_get_format(video, VIDEO_EP_OUT, &fmt)) {
		LOG_ERR("Unable to retrieve video format");
		return 0;
	}
	fmt.width = 320,
	fmt.height = 240,
	fmt.pixelformat = VIDEO_PIX_FMT_JPEG;
	video_set_format(video, VIDEO_EP_OUT, &fmt);

	printk("- Default format: %c%c%c%c %ux%u\n", (char)fmt.pixelformat,
	       (char)(fmt.pixelformat >> 8),
	       (char)(fmt.pixelformat >> 16),
	       (char)(fmt.pixelformat >> 24),
	       fmt.width, fmt.height);

	/* Size to allocate for each buffer */
	bsize = 1024;

	/* Alloc video buffers and enqueue for capture */
	for (i = 0; i < ARRAY_SIZE(buffers); i++) {
		buffers[i] = video_buffer_alloc(bsize);
		if (buffers[i] == NULL) {
			LOG_ERR("Unable to alloc video buffer");
			return 0;
		}

		video_enqueue(video, VIDEO_EP_OUT, buffers[i]);
	}
	printk("Prepare Capture started\n");
	/* Start video capture */
	if (video_stream_start(video)) {
		LOG_ERR("Unable to start capture (interface)");
		return 0;
	}

	printk("Capture started\n");

	/* Grab video frames */
	while (1) {
		int err;
		enum video_frame_fragmented_status f_status;
		err = video_dequeue(video, VIDEO_EP_OUT, &vbuf, K_FOREVER);
		if (err) {
			LOG_ERR("Unable to dequeue video buf");
			return 0;
		}
		 f_status = vbuf->flags;
	
		if (f_status == VIDEO_BUF_EOF){
			printk(" Got frame %u!;  size: %u; timestamp %u ms\n",
		       frame++, vbuf->bytesframe, vbuf->timestamp);
		}

		err = video_enqueue(video, VIDEO_EP_OUT, vbuf);
		if (err) {
			LOG_ERR("Unable to requeue video buf");
			return 0;
		}
	}
}

The Arducam mega is an low power, rolling shutter camera, support connect one or more cameras any Microcontroller. It provides high-quality image capture and processing capabilities, making it highly suitable for various application fields, including machine vision, image recognition, and robotics, among others. Signed-off-by: Lee Jackson <[email protected]>

This example is a full-featured sample for the Arducam Mega camera driver. By using serial communication with a PC software, it can capture images, display them, and also control camera settings such as exposure and gain. Signed-off-by: Lee Jackson <[email protected]>

drivers/video/arducam_mega.c

danieldegrasse · 2024-06-01T18:26:19Z

Looking at this API, I'm unclear how the consumer determines what size of framebuffer they should provide to the video device. In the case of the arducam, is the size essentially arbitrary? IE the application could provided 10 1KiB byte buffers, or 1 10KiB buffer, and the camera would work either way?

The other use case I'd like to try to cover with a "partial frame" API is one where the camera driver "slices" the frame into segments. For example, a 320x240 frame might be divided into 8 320x30 pixel buffers, which would allow a low memory device to stream QVGA frames in chunks. The issue here is how to tell the application what size of framebuffer is required, since in this case the size of each framebuffer is fixed.

In #72827, the approach I used was to provide a vbufs_per_frame field in the video_caps structure: https://github.com/zephyrproject-rtos/zephyr/pull/72827/files#diff-70c4de6949b97c13ac893b4bfb16fbcc433593fbfa96ec8947bb5cb83c4d04bc. This way, the video consumer can determine how many vbufs are included in one frame. However, this does not account for the case described here, where the size of the vbuf provided appears to be flexible.

@loicpoulain do you have any thoughts here? Maybe we add a special value to vbufs_per_frame, like VIDEO_VBUFS_VARIABLE, to indicate the driver can accept variably sized video buffers?

ArduCAM · 2024-06-03T00:57:03Z

Looking at this API, I'm unclear how the consumer determines what size of framebuffer they should provide to the video device. In the case of the arducam, is the size essentially arbitrary? IE the application could provided 10 1KiB byte buffers, or 1 10KiB buffer, and the camera would work either way?

The other use case I'd like to try to cover with a "partial frame" API is one where the camera driver "slices" the frame into segments. For example, a 320x240 frame might be divided into 8 320x30 pixel buffers, which would allow a low memory device to stream QVGA frames in chunks. The issue here is how to tell the application what size of framebuffer is required, since in this case the size of each framebuffer is fixed.

In #72827, the approach I used was to provide a vbufs_per_frame field in the video_caps structure: https://github.com/zephyrproject-rtos/zephyr/pull/72827/files#diff-70c4de6949b97c13ac893b4bfb16fbcc433593fbfa96ec8947bb5cb83c4d04bc. This way, the video consumer can determine how many vbufs are included in one frame. However, this does not account for the case described here, where the size of the vbuf provided appears to be flexible.

@loicpoulain do you have any thoughts here? Maybe we add a special value to vbufs_per_frame, like VIDEO_VBUFS_VARIABLE, to indicate the driver can accept variably sized video buffers?

Yes，For arducam spi camera, the the size of each segments is flexible. the camera have a hardware frambuffer, so read image data is very flexible. it support read one by one or block read. Driver gets each frame size and send to user space through multi segments, due to some platform's memory limitation， each segments is flexible, even one byte. For compressed data such as jpeg format, the frame size is flexible and not stable. so for the last vbuf，it will contains some supplementary data, if the driver can accept variably sized video buffers, i think it‘s great.

danieldegrasse · 2024-06-03T17:38:06Z

@loicpoulain and @ArduCAM, I've updated #72827 with commits to demonstrate how I think we might merge these two methods of handling partial video frames. Essentially, a driver would set the VIDEO_CAP_VARIABLE_VBUFS flag to indicate that it did not require a fixed video buffer size. Otherwise, the application should provide video buffer frames equal in size to pitch * height / vbufs_per_frame. The video driver will set the VIDEO_BUF_EOF flag on the last buffer in a frame (for drivers that use full frames, every buffer will have this flag set).

I'm interested to hear any feedback on this approach.

josuah

Thank you for adding Zephyr support for this camera!

josuah · 2024-07-12T11:40:11Z

drivers/video/arducam_mega.c

+	ret |= arducam_mega_await_bus_idle(&cfg->bus, 3);
+	ret |= arducam_mega_write_reg(&cfg->bus, CAM_REG_MANUAL_GAIN_BIT_9_8, (value >> 8) & 0xff);
+	ret |= arducam_mega_await_bus_idle(&cfg->bus, 10);
+	ret |= arducam_mega_write_reg(&cfg->bus, CAM_REG_MANUAL_GAIN_BIT_7_0, value & 0xff);
+	ret |= arducam_mega_await_bus_idle(&cfg->bus, 10);


I am personally a fan with this compact style of error checking, although in Zephyr, the return values are negatives of values from errno.h. This means that OR-ing them would scramble the value, and eventually give a bad error code.

The best would be to convert it to something like this this, even though this takes-up 4 lines instead of 1:

ret = arducam_mega_await_bus_idle(&cfg->bus, 3); if (ret < 0) { return ret; }

drivers/video/arducam_mega.c

josuah · 2024-07-12T12:02:33Z

samples/drivers/video/arducam_mega_full-featured/src/main.c

+#define RESET_CAMERA             0XFF
+#define SET_PICTURE_RESOLUTION   0X01
+#define SET_VIDEO_RESOLUTION     0X02
+#define SET_BRIGHTNESS           0X03
+#define SET_CONTRAST             0X04
+#define SET_SATURATION           0X05
+#define SET_EV                   0X06
+#define SET_WHITEBALANCE         0X07
+#define SET_SPECIAL_EFFECTS      0X08
+#define SET_FOCUS_ENABLE         0X09
+#define SET_EXPOSURE_GAIN_ENABLE 0X0A
+#define SET_WHITE_BALANCE_ENABLE 0X0C
+#define SET_MANUAL_GAIN          0X0D
+#define SET_MANUAL_EXPOSURE      0X0E
+#define GET_CAMERA_INFO          0X0F
+#define TAKE_PICTURE             0X10
+#define SET_SHARPNESS            0X11
+#define DEBUG_WRITE_REGISTER     0X12
+#define STOP_STREAM              0X21
+#define GET_FRM_VER_INFO         0X30
+#define GET_SDK_VER_INFO         0X40
+#define SET_IMAGE_QUALITY        0X50
+#define SET_LOWPOWER_MODE        0X60


This is an interesting implementation, but looks too complex for a sample: expected to be the simplest possible way to implement a driver.

This gives the impression that the Ardcuam driver does not work with the generic Zephyr API, which is false as you properly integrated everything quite nicely!

How about trying to get it to work with the existing sample here?
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/video/capture

This could also help promoting this camera by showing that no extra application needs to be written to control the Arucam.

This would also allow shrinking the amount of code to review as part of this PR which is in review since too long already (sorry about this!).

drivers/video/arducam_mega.c

josuah · 2024-07-12T14:19:52Z

drivers/video/arducam_mega.c

+{
+	while ((arducam_mega_read_reg(spec, CAM_REG_SENSOR_STATE) & 0x03) != SENSOR_STATE_IDLE) {
+		if (tries-- == 0) {
+			return -1;


Often Zephyr uses -errno as return value as a hint of where the error comes from.
Maybe here it is return -EAGAIN as it is a timeout? Or maybe return -EIO; for it is related to communication...

josuah · 2024-07-12T17:26:05Z

drivers/video/arducam_mega.c

+
+	ret |= arducam_mega_write_reg(&cfg->bus, CAM_REG_SHARPNESS_CONTROL, level);
+
+	if (ret == -1) {


Given the -errno being returned for errors, I suppose this would need to be converted to ret < 0

josuah · 2024-07-12T17:27:15Z

drivers/video/arducam_mega.c

+		drv_data->info = &mega_infos[0];
+		break;


This looks like missing a case, or might need to be removed.

josuah · 2024-07-28T20:21:55Z

It sounds like it is possible to merge this PR without introducing the extra capability immediately:

The flags are information about what happened: If a frame did not fit the buffer, it tells so in the vbuf->flags.
The caps() extensions tell how the device will behave: It will help the user sizing the buffers correctly.

But it looks like Arducam does not need any caps() extension, so can be merged before they get introduced.

If a buffer is too small, Arducam Mega will fragment the data with VIDEO_BUF_FRAG.
If a buffer is too long, Arducam Mega will fill it partially with VIDEO_BUF_EOF on each frame.

josuah · 2024-07-28T22:06:04Z

include/zephyr/drivers/video.h

+enum video_frame_fragmented_status {
+	VIDEO_BUF_FRAG,
+	VIDEO_BUF_EOF,
+};


Suggested change

enum video_frame_fragmented_status {

VIDEO_BUF_FRAG,

VIDEO_BUF_EOF,

};

#define VIDEO_BUF_FRAG BIT(0)

#define VIDEO_BUF_EOF BIT(1)

I think this is what @loicpoulain suggested here.

Video buffers did not precise whether they contained a whole frame, or a fragment of a frame. Adding a flag struct as well as a total frame field allows video devices to tell whether they produced - a complete frame (with VIDEO_BUF_EOF and no VIDEO_BUF_FRAG), - a partial frame (with VIDEO_BUF_FRAG), - a last frame (with VIDEO_BUF_EOF), The video devices that do not support fragmentation currently ignore this flag. As discussed in zephyrproject-rtos#66994 and zephyrproject-rtos#72827. Co-authored-by: Lee <[email protected]> Co-authored-by: Daniel DeGrasse <[email protected]> Signed-off-by: Josuah Demangeon <[email protected]>

github-actions · 2024-09-27T00:32:58Z

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

loicpoulain · 2024-10-11T19:52:31Z

@ArduCAM wondering if you could rebase and address latest @josuah comments, I would like to move forward on this.

danieldegrasse · 2024-10-14T19:01:17Z

@ArduCAM wondering if you could rebase and address latest @josuah comments, I would like to move forward on this.

Could you also take a look at the changes in #72827 and see if those API additions would handle this camera?

kartben · 2024-11-25T10:56:06Z

@ArduCAM -- I know this has been open for a really long time, but as a lot has happened around video recently, I feel like addressing the remaining comments should help us get this really close to be mergeable. Thanks!

zephyrbot added area: Video Video subsystem area: Devicetree Binding PR modifies or adds a Device Tree binding labels Dec 25, 2023

zephyrbot requested review from galak and loicpoulain December 25, 2023 09:35

zephyrbot assigned galak Dec 25, 2023

marcusfolkesson reviewed Dec 25, 2023

View reviewed changes

drivers/video/Kconfig.arducam_mega Show resolved Hide resolved

bjarki-andreasen requested changes Dec 25, 2023

View reviewed changes

drivers/video/arducam_mega.c Outdated Show resolved Hide resolved

drivers/video/arducam_mega.c Show resolved Hide resolved

drivers/video/arducam_mega.c Show resolved Hide resolved

drivers/video/arducam_mega.c Outdated Show resolved Hide resolved

loicpoulain reviewed Dec 26, 2023

View reviewed changes

ArduCAM force-pushed the add_arducam_mega_driver branch from 8ba42f5 to 8775fb0 Compare December 27, 2023 00:58

ArduCAM force-pushed the add_arducam_mega_driver branch from 10e5c85 to eed8f09 Compare January 3, 2024 09:05

kartben previously requested changes Jan 4, 2024

View reviewed changes

ArduCAM force-pushed the add_arducam_mega_driver branch 5 times, most recently from 1484bea to 145fb29 Compare January 5, 2024 07:27

ArduCAM force-pushed the add_arducam_mega_driver branch from 05f138a to d847472 Compare January 10, 2024 03:20

loicpoulain reviewed Jan 10, 2024

View reviewed changes

bjarki-andreasen previously approved these changes Jan 10, 2024

View reviewed changes

ArduCAM dismissed bjarki-andreasen’s stale review via b44ed2f January 10, 2024 08:57

ArduCAM force-pushed the add_arducam_mega_driver branch from d847472 to b44ed2f Compare January 10, 2024 08:57

Lee Jackson added 2 commits May 22, 2024 10:33

drivers: video: add some video controls ID

1164c58

Add some common camera's control: VIDEO_CID_CAMERA_EXPOSURE_AUTO, VIDEO_CID_CAMERA_GAIN_AUTO, VIDEO_CID_CAMERA_WHITE_BAL_AUTO, VIDEO_CID_JPEG_COMPRESSION_QUALITY Signed-off-by: Lee Jackson <[email protected]>

driver: video: add the fields of the video_buffer structure

c78faad

Adding frame length and fragmented frame status to indicate certain information about the frame when the video buffer is smaller than the frame length. Signed-off-by: Lee Jackson <[email protected]>

ArduCAM force-pushed the add_arducam_mega_driver branch from 681bf99 to 779062f Compare May 22, 2024 02:34

Lee Jackson added 2 commits May 23, 2024 09:52

ArduCAM force-pushed the add_arducam_mega_driver branch from 779062f to 60de7c4 Compare May 23, 2024 01:55

ArduCAM commented May 25, 2024

View reviewed changes

drivers/video/arducam_mega.c Show resolved Hide resolved

ArduCAM requested review from demonday and loicpoulain May 27, 2024 12:58

nashif unassigned galak Jun 14, 2024

josuah requested changes Jul 12, 2024

View reviewed changes

josuah mentioned this pull request Jul 27, 2024

drivers: video: Move the sensors to their dedicated directory #73013

Closed

josuah reviewed Jul 28, 2024

View reviewed changes

This was referenced Sep 12, 2024

usb: device_next: new USB Video Class (UVC) implementation #76798

Open

drivers: video: esp32s3: Add set_signal video api function #78566

Merged

github-actions bot added the Stale label Sep 27, 2024

github-actions bot removed the Stale label Oct 12, 2024


		#define DT_DRV_COMPAT arducam_mega

		#include <zephyr/drivers/video/arducam_mega.h>


		ret \|= arducam_mega_write_reg(&cfg->bus, CAM_REG_SHARPNESS_CONTROL, level);

		if (ret == -1) {

drivers: video: Add support for arducam mega #66994

Are you sure you want to change the base?

drivers: video: Add support for arducam mega #66994

Conversation

ArduCAM commented Dec 25, 2023

github-actions bot commented Dec 25, 2023

bjarki-andreasen commented Dec 25, 2023

bjarki-andreasen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

loicpoulain Jan 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

loicpoulain commented Dec 26, 2023

ArduCAM commented Jan 2, 2024

ArduCAM commented Jan 2, 2024

bjarki-andreasen commented Jan 2, 2024

ArduCAM commented Jan 4, 2024

loicpoulain Jan 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bjarki-andreasen left a comment

Choose a reason for hiding this comment

kartben commented Jan 10, 2024

loicpoulain commented May 20, 2024

ArduCAM commented May 21, 2024

ArduCAM commented May 22, 2024 • edited Loading

ArduCAM commented May 22, 2024 • edited Loading

danieldegrasse commented Jun 1, 2024

ArduCAM commented Jun 3, 2024 • edited Loading

danieldegrasse commented Jun 3, 2024 • edited Loading

josuah left a comment • edited Loading

Choose a reason for hiding this comment

josuah Jul 12, 2024 • edited Loading

Choose a reason for hiding this comment

josuah Jul 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josuah Jul 12, 2024 • edited Loading

Choose a reason for hiding this comment

josuah Jul 12, 2024 • edited Loading

Choose a reason for hiding this comment

josuah commented Jul 28, 2024

josuah Jul 28, 2024 • edited Loading

Choose a reason for hiding this comment

github-actions bot commented Sep 27, 2024

loicpoulain commented Oct 11, 2024

danieldegrasse commented Oct 14, 2024 • edited Loading

kartben commented Nov 25, 2024

loicpoulain Jan 3, 2024 •

edited

Loading

loicpoulain Jan 10, 2024 •

edited

Loading

ArduCAM commented May 22, 2024 •

edited

Loading

ArduCAM commented May 22, 2024 •

edited

Loading

ArduCAM commented Jun 3, 2024 •

edited

Loading

danieldegrasse commented Jun 3, 2024 •

edited

Loading

josuah left a comment •

edited

Loading

josuah Jul 12, 2024 •

edited

Loading

josuah Jul 12, 2024 •

edited

Loading

josuah Jul 12, 2024 •

edited

Loading

josuah Jul 12, 2024 •

edited

Loading

josuah Jul 28, 2024 •

edited

Loading

danieldegrasse commented Oct 14, 2024 •

edited

Loading